[jira] Commented: (ZOOKEEPER-907) Spurious KeeperErrorCode = Session moved messages
[ https://issues.apache.org/jira/browse/ZOOKEEPER-907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12927020#action_12927020 ] Mahadev konar commented on ZOOKEEPER-907: - thats ok with me ben. Can you review and +1 the patch it its all good to go? Spurious KeeperErrorCode = Session moved messages --- Key: ZOOKEEPER-907 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-907 Project: Zookeeper Issue Type: Bug Affects Versions: 3.3.1 Reporter: Vishal K Assignee: Vishal K Priority: Blocker Fix For: 3.3.2, 3.4.0 Attachments: ZOOKEEPER-907.patch, ZOOKEEPER-907.patch_v2 The sync request does not set the session owner in Request. As a result, the leader keeps printing: 2010-07-01 10:55:36,733 - INFO [ProcessThread:-1:preprequestproces...@405] - Got user-level KeeperException when processing sessionid:0x298d3b1fa9 type:sync: cxid:0x6 zxid:0xfffe txntype:unknown reqpath:/ Error Path:null Error:KeeperErrorCode = Session moved -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-872) Small fixes to PurgeTxnLog
[ https://issues.apache.org/jira/browse/ZOOKEEPER-872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-872: Status: Patch Available (was: Open) Small fixes to PurgeTxnLog --- Key: ZOOKEEPER-872 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-872 Project: Zookeeper Issue Type: Bug Affects Versions: 3.3.1 Reporter: Vishal K Assignee: Vishal K Priority: Minor Fix For: 3.4.0 Attachments: ZOOKEEPER-872 PurgeTxnLog forces us to have at least 2 backups (by having count = 3. Also, it prints to stdout instead of using Logger. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-850) Switch from log4j to slf4j
[ https://issues.apache.org/jira/browse/ZOOKEEPER-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12927036#action_12927036 ] Patrick Hunt commented on ZOOKEEPER-850: Hi Olaf, thanks for the patch. A couple questions/comments: 1) can you create this patch against trunk? We only put bug fixes into the fix releases, so this would be slated for 3.4.0 release (current trunk). 2) do any of the shell scripts need to be updated? (bin directory) 3) I see references to log4j in the build.xml file(s). Do any of these need to be upated? It would be good if you could build a release (ant tar) and verify that the built archive can run zk server/client via the bin scripts. 4) It looks like the documentation also needs to be updated, do a egrep -Ri log4j src/docs/src/documentation/ log4j from the toplevel. We should at least update the existing docs, also it would be helpful to include addl information to help both users and developers make the switch. 5) we typically create release notes for a release, it would be good to document in this JIRA (the rel notes section) any details we should include in the release notes documentation that goes along with the release. Some short statement detailing the change an any impact (you've given some detail in the comments, basically wrapping it up into something short/simple for users to follow during upgrade). Thanks! Switch from log4j to slf4j -- Key: ZOOKEEPER-850 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-850 Project: Zookeeper Issue Type: Improvement Components: java client Affects Versions: 3.3.1 Reporter: Olaf Krische Assignee: Olaf Krische Fix For: 3.4.0 Attachments: ZOOKEEPER-3.3.1-log4j-slf4j-20101031.patch.bz2 Hello, i would like to see slf4j integrated into the zookeeper instead of relying explicitly on log4j. slf4j is an abstract logging framework. There are adapters from slf4j to many logger implementations, one of them is log4j. The decision which log engine to use i dont like to make so early. This would help me to embed zookeeper in my own applications (which use a different logger implemenation, but slf4j is the basis) What do you think? (as i can see, those slf4j request flood all other projects on apache as well :-) Maybe for 3.4 or 4.0? I can offer a patchset, i have experience in such an migration already. :-) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-909) Extract NIO specific code from ClientCnxn
[ https://issues.apache.org/jira/browse/ZOOKEEPER-909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12927045#action_12927045 ] Benjamin Reed commented on ZOOKEEPER-909: - the patch looks good. are you proposing that we commit it? or are you still working on it? i don't mind pushing off the javadoc for a bit if you think things might change. (although it would be nice to get that class more firmed up before we commit really...) we should get the property doc in before we commit since that will not change. One other nit, if you are willing: calling the ClientCxnSocket socket and using getSocket is a bit confusing since ClientCnxnSocket does not extend socket. It's a bit more verbose, but more clear if you call the member and method clientCxnSocket and getClientCnxnSocket. Extract NIO specific code from ClientCnxn - Key: ZOOKEEPER-909 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-909 Project: Zookeeper Issue Type: Sub-task Components: java client Reporter: Thomas Koch Assignee: Thomas Koch Fix For: 3.4.0 Attachments: ZOOKEEPER-909.patch, ZOOKEEPER-909.patch, ZOOKEEPER-909.patch This patch is mostly the same patch as my last one for ZOOKEEPER-823 minus everything Netty related. This means this patch only extract all NIO specific code in the class ClientCnxnSocketNIO which extends ClientCnxnSocket. I've redone this patch from current trunk step by step now and couldn't find any logical error. I've already done a couple of successful test runs and will continue to do so this night. It would be nice, if we could apply this patch as soon as possible to trunk. This allows us to continue to work on the netty integration without blocking the ClientCnxn class. Adding Netty after this patch should be only a matter of adding the ClientCnxnSocketNetty class with the appropriate test cases. You could help me by reviewing the patch and by running it on whatever test server you have available. Please send me any complete failure log you should encounter to thomas at koch point ro. Thx! Update: Until now, I've collected 8 successful builds in a row! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-872) Small fixes to PurgeTxnLog
[
https://issues.apache.org/jira/browse/ZOOKEEPER-872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12927082#action_12927082
]
Patrick Hunt commented on ZOOKEEPER-872:
Hi Vishal, I noticed a couple issues.
This class is a command line utility. As such we are outputting to both the
command line and to the log. The usage() in particular should go to std out so
that the user will see it regardless of the log settings (fine if you want to
output it to LOG as well, but I think this is unnecessary).
good catch on the error handling for this:
public static void purge(File dataDir, File snapDir, int num) throws
IOException {
-if (num 3) {
-throw new IllegalArgumentException(count should be greater than
3);
+if (num 2) {
+throw new IllegalArgumentException(count should be greater than
1);
}
However the number 3 was chosen to ensure that ppl don't shoot themselves in
the foot (if the most recent logs get corrupted we'll fall back to the prior
when attempting to recover). There really should be a comment to this effect
(would be good to add). I don't know how Mahadev feels on this setting (min 3
vs some other number) but he might have more insight as IIRC he implemented
this originally.
this following is there to provide feedback to the user when running on command
line:
-System.out.println(Removing file: +
-DateFormat.getDateTimeInstance().format(f.lastModified())+
-\t+f.getPath());
again, regardless of logging setup.
Perhaps we should have a -q option that turns off the CLI logging and just
logs to the log file? I know this has been an issue previously (stdout/err)
given that cron will spitout emails by default containing stdout/err.
Also, is there a test for this? If you're up to it would be great to add.
Small fixes to PurgeTxnLog
---
Key: ZOOKEEPER-872
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-872
Project: Zookeeper
Issue Type: Bug
Affects Versions: 3.3.1
Reporter: Vishal K
Assignee: Vishal K
Priority: Minor
Fix For: 3.4.0
Attachments: ZOOKEEPER-872
PurgeTxnLog forces us to have at least 2 backups (by having count = 3. Also,
it prints to stdout instead of using Logger.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-872) Small fixes to PurgeTxnLog
[ https://issues.apache.org/jira/browse/ZOOKEEPER-872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12927127#action_12927127 ] Vishal K commented on ZOOKEEPER-872: Hi Pat, The current code prints to stdout. We have a RMI service that has ZK server embedded in it. We do this so that we can run/start/stop ZK across platforms without having to write platform specific scripts. In this server, we start a thread that periodically calls PurgeTxnlog.purge(). As you pointed out, we should have a -q flag to direct to log instead stdout to statisfy both the approaches. I will make that change. We chose number 2 here because we think having only one backup will be enough. It is not clear to us under what conditions the additional backup will be useful. Backups are useful under the following scenario (correct me if I am wrong): 1. The current ZooKeeper transaction log and/or snapshot is corrupted, but the past snapshots and transaction logs are ok. Corrupting can mean either disk file corruption or corrupting of transaction entries in the log. We store ZooKeeper data on mirrored disks. 2. The application itself made some errors that requires reverting back to the older version. For the first point, having one additional backup would suffice. The second point is really tricky. I am not sure how the application can decide which snapshot to revert to. I think in most cases it will be trial and error. It is not clear to me how to estimate the number of backups needed. Also, it is not clear how one would go about going back in time. I looked at LogFormatter utility and that utility does not help much in undoing the erroneous transactions for case 2 above. In general, I think it is good to enforce users to have a minimum of one backup. Related question: Is there hash on the log files (or internal tree structures) that can tell the ZooKeeper server if the logs are corrupted. If yes, the zookeeper server can verify the hash during startup and take some action based on that. For example, make sure that it never becomes a leader until it gets the correct snapshot from the existing leader (otherwise it may endup corrupting other server's log). Corrupting here refers to the case where the file is readable, but one or more transactions in the log are bad. I am not sure if there is a test for this. If I remember correctly, there is a bug that causes the purge() function to leave behind one addition log file. Please refer to my question above about findNRecentSnapshots(). I can add a test or modify the pruge utlity once we have concluded this discussion. Small fixes to PurgeTxnLog --- Key: ZOOKEEPER-872 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-872 Project: Zookeeper Issue Type: Bug Affects Versions: 3.3.1 Reporter: Vishal K Assignee: Vishal K Priority: Minor Fix For: 3.4.0 Attachments: ZOOKEEPER-872 PurgeTxnLog forces us to have at least 2 backups (by having count = 3. Also, it prints to stdout instead of using Logger. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-850) Switch from log4j to slf4j
[ https://issues.apache.org/jira/browse/ZOOKEEPER-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olaf Krische updated ZOOKEEPER-850: --- Attachment: ZOOKEEPER-3.4.0-log4j-slf4j-20101102.patch.bz2 Release-Notes: - replaces as far as possible the log4j with slf4j code (also in contrib for bookkeeper, zooinspector,rest,loggraph) - you must add slf4j-api-1.6.1jar and slf4j-log4j12-1.6.1 to the classpath! - log4j remains as the final logger, some code still depends directly on it (there is work to do...) Switch from log4j to slf4j -- Key: ZOOKEEPER-850 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-850 Project: Zookeeper Issue Type: Improvement Components: java client Affects Versions: 3.3.1 Reporter: Olaf Krische Assignee: Olaf Krische Fix For: 3.4.0 Attachments: ZOOKEEPER-3.3.1-log4j-slf4j-20101031.patch.bz2, ZOOKEEPER-3.4.0-log4j-slf4j-20101102.patch.bz2 Hello, i would like to see slf4j integrated into the zookeeper instead of relying explicitly on log4j. slf4j is an abstract logging framework. There are adapters from slf4j to many logger implementations, one of them is log4j. The decision which log engine to use i dont like to make so early. This would help me to embed zookeeper in my own applications (which use a different logger implemenation, but slf4j is the basis) What do you think? (as i can see, those slf4j request flood all other projects on apache as well :-) Maybe for 3.4 or 4.0? I can offer a patchset, i have experience in such an migration already. :-) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
