ZooKeeper_branch33_solaris - Build # 644 - Still Failing
See https://builds.apache.org/job/ZooKeeper_branch33_solaris/644/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 108173 lines...] [junit] 2013-09-12 07:09:29,441 - INFO [main:ZooKeeperServer@154] - Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 6 datadir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris/trunk/build/test/tmp/test3231459883631206712.junit.dir/version-2 snapdir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris/trunk/build/test/tmp/test3231459883631206712.junit.dir/version-2 [junit] 2013-09-12 07:09:29,442 - INFO [main:NIOServerCnxn$Factory@143] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2013-09-12 07:09:29,443 - INFO [main:FileSnap@82] - Reading snapshot /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris/trunk/build/test/tmp/test3231459883631206712.junit.dir/version-2/snapshot.0 [junit] 2013-09-12 07:09:29,447 - INFO [main:FileTxnSnapLog@256] - Snapshotting: b [junit] 2013-09-12 07:09:29,449 - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2013-09-12 07:09:29,450 - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn$Factory@251] - Accepted socket connection from /127.0.0.1:56724 [junit] 2013-09-12 07:09:29,451 - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@1237] - Processing stat command from /127.0.0.1:56724 [junit] 2013-09-12 07:09:29,451 - INFO [Thread-4:NIOServerCnxn$StatCommand@1153] - Stat command output [junit] 2013-09-12 07:09:29,452 - INFO [Thread-4:NIOServerCnxn@1435] - Closed socket connection for client /127.0.0.1:56724 (no session established for client) [junit] ensureOnly:[InMemoryDataTree, StandaloneServer_port] [junit] expect:InMemoryDataTree [junit] found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] expect:StandaloneServer_port [junit] found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2013-09-12 07:09:29,459 - INFO [main:ClientBase@408] - STOPPING server [junit] 2013-09-12 07:09:29,461 - INFO [SyncThread:0:SyncRequestProcessor@151] - SyncRequestProcessor exited! [junit] 2013-09-12 07:09:29,461 - INFO [ProcessThread:-1:PrepRequestProcessor@128] - PrepRequestProcessor exited loop! [junit] 2013-09-12 07:09:29,461 - INFO [main:FinalRequestProcessor@370] - shutdown of request processor complete [junit] 2013-09-12 07:09:29,463 - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] ensureOnly:[] [junit] 2013-09-12 07:09:29,464 - INFO [main:ClientBase@401] - STARTING server [junit] 2013-09-12 07:09:29,465 - INFO [main:ZooKeeperServer@154] - Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 6 datadir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris/trunk/build/test/tmp/test3231459883631206712.junit.dir/version-2 snapdir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris/trunk/build/test/tmp/test3231459883631206712.junit.dir/version-2 [junit] 2013-09-12 07:09:29,466 - INFO [main:NIOServerCnxn$Factory@143] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2013-09-12 07:09:29,467 - INFO [main:FileSnap@82] - Reading snapshot /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris/trunk/build/test/tmp/test3231459883631206712.junit.dir/version-2/snapshot.b [junit] 2013-09-12 07:09:29,470 - INFO [main:FileTxnSnapLog@256] - Snapshotting: b [junit] 2013-09-12 07:09:29,472 - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2013-09-12 07:09:29,473 - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn$Factory@251] - Accepted socket connection from /127.0.0.1:56726 [junit] 2013-09-12 07:09:29,473 - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@1237] - Processing stat command from /127.0.0.1:56726 [junit] 2013-09-12 07:09:29,474 - INFO [Thread-5:NIOServerCnxn$StatCommand@1153] - Stat command output [junit] 2013-09-12 07:09:29,475 - INFO [Thread-5:NIOServerCnxn@1435] - Closed socket connection for client /127.0.0.1:56726 (no session established for client) [junit] ensureOnly:[InMemoryDataTree, StandaloneServer_port] [junit] expect:InMemoryDataTree [junit] found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] expect:StandaloneServer_port [junit] found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2013-09-12 07:09:29,480 - INFO
ZooKeeper-trunk-solaris - Build # 668 - Still Failing
See https://builds.apache.org/job/ZooKeeper-trunk-solaris/668/ ### ## LAST 60 LINES OF THE CONSOLE ### Started by timer FATAL: null java.lang.NullPointerException at hudson.model.Slave.createLauncher(Slave.java:347) at hudson.model.AbstractBuild$AbstractBuildExecution.createLauncher(AbstractBuild.java:612) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:543) at hudson.model.Run.execute(Run.java:1603) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:246) ### ## FAILED TESTS (if any) ## No tests ran.
[jira] [Commented] (ZOOKEEPER-1718) Support JLine 2
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13765303#comment-13765303 ] Flavio Junqueira commented on ZOOKEEPER-1718: - I think this issue is related to ZOOKEEPER-1655, no? Support JLine 2 --- Key: ZOOKEEPER-1718 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1718 Project: ZooKeeper Issue Type: Test Reporter: Christopher Tubbs Priority: Critical Fix For: 3.5.0 Attachments: ZOOKEEPER-1718.patch not fixed -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1750) Race condition producing NPE in NIOServerCnxn.toString
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13765340#comment-13765340 ] Hudson commented on ZOOKEEPER-1750: --- SUCCESS: Integrated in ZooKeeper-trunk #2053 (See [https://builds.apache.org/job/ZooKeeper-trunk/2053/]) ZOOKEEPER-1750 Handle NIOServerCnxn#toString returning null (Rakesh R via michim) (michim: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1522079) * /zookeeper/trunk/src/java/test/org/apache/zookeeper/server/NIOServerCnxnTest.java Race condition producing NPE in NIOServerCnxn.toString -- Key: ZOOKEEPER-1750 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1750 Project: ZooKeeper Issue Type: Bug Components: server Affects Versions: 3.5.0 Reporter: Helen Hastings Assignee: Rakesh R Priority: Minor Fix For: 3.5.0 Attachments: 0001-ZOOKEEPER-1750-trunk-version.patch, 0002-ZOOKEEPER-1750-trunk-version.patch, 0003-ZOOKEEPER-1750-branch-3_4.patch, 0004-ZOOKEEPER-1750-trunk-version-modified-test-case-assertion.patch The socket is closed and the variable sock is set to null for normal reasons, but the toString method is called before sock can be set again, producing a NullPointerException. Stack trace: 2013-08-29 01:49:19,991 6277 [CommitProcWorkThread-3] WARN org.apache.zookeeper.server.WorkerService - Unexpected exception java.lang.NullPointerException at org.apach.zookeeper.server.NIOServerCnxn.toString(NIOServerCnxn.java:961) at java.lang.String.valueOf(String.java:2854) at java.lang.StringBuilder.append(StringBuilder.java:128) at org.apache.zookeeper.server.NIOServerCnxn.process(NIOServerCnxn.java:1104) at org.apache.zookeeper.server.WatchManager.triggerWatch(WatchManager.java:120) at org.apache.zookeeper.server.WatchManager.triggerWatch(WatchManager.java:92) at org.apache.zookeeper.server.DataTree.createNode(DataTree.java:544) at org.apache.zookeeper.server.DataTree.processTxn(DataTree.java:805) at org.apache.zookeeper.server.ZKDatabase.processTxn(ZKDatabase.java:319) at org.apache.zookeeper.server.ZooKeeperServer.processTxn(ZooKeeperServer.java:967) at org.apache.zookeeper.server.FinalRequestProcessor.processRequest(FinalRequestProcessor.java:115) at org.apache.zookeeper.server.quorum.Leader$ToBeAppliedRequestProcessor.processRequest(Leader.java:859) at org.apache.zookeeper.server.quorum.CommitProcessor$CommitWorkRequest.doWork(CommitProcessor.java:271) at org.apache.zookeeper.server.WorkerService$ScheduledWorkRequest.run(WorkerService.java:152) 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:722) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1747) Zookeeper server fails to start if transaction log file is corrupted
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13765392#comment-13765392
]
Germán Blanco commented on ZOOKEEPER-1747:
--
We have seen this issue also with inconsistent state between acceptedEpoch,
currentEpoch and the transaction log. In that case the error is:
{noformat}
2013-09-12 12:30:51,586 [myid:10] - ERROR [main:QuorumPeer@453] - Unable to
load database on disk
java.io.IOException: The current epoch, 6, is older than the last zxid,
34359738487
at
org.apache.zookeeper.server.quorum.QuorumPeer.loadDataBase(QuorumPeer.java:435)
at
org.apache.zookeeper.server.quorum.QuorumPeer.start(QuorumPeer.java:409)
at
org.apache.zookeeper.server.quorum.QuorumPeerMain.runFromConfig(QuorumPeerMain.java:151)
at
org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:111)
at
org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:78)
2013-09-12 12:30:51,587 [myid:10] - ERROR [main:QuorumPeerMain@89] - Unexpected
exception, exiting abnormally
java.lang.RuntimeException: Unable to run quorum server
at
org.apache.zookeeper.server.quorum.QuorumPeer.loadDataBase(QuorumPeer.java:454)
at
org.apache.zookeeper.server.quorum.QuorumPeer.start(QuorumPeer.java:409)
at
org.apache.zookeeper.server.quorum.QuorumPeerMain.runFromConfig(QuorumPeerMain.java:151)
at
org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:111)
at
org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:78)
Caused by: java.io.IOException: The current epoch, 6, is older than the last
zxid, 34359738487
at
org.apache.zookeeper.server.quorum.QuorumPeer.loadDataBase(QuorumPeer.java:435)
... 4 more
{noformat}
I guess force-ignore means that the server just ignores whatever is in the
disk and starts with zxid=0, or?
Zookeeper server fails to start if transaction log file is corrupted
Key: ZOOKEEPER-1747
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1747
Project: ZooKeeper
Issue Type: Bug
Components: server
Affects Versions: 3.4.5
Environment: Solaris10/x86, Java 1.6
Reporter: Sergey Maslyakov
On multiple occasions when ZK was not able to write out a transaction log or
a snapshot file, the consequent attempt to restart the server fails. Usually
it happens when the underlying file system filled up; thus, preventing ZK
server from writing out consistent data file.
Upon start-up, the server reads in the snapshot and the transaction log. If
the deserializer fails and throws an exception, server terminates. Please see
the stack trace below.
Server not coming up for whatever reason is often an undesirable condition.
It would be nice to have an option to force-ignore parsing errors,
especially, in the transaction log. A check sum on the data could be a
possible solution to ensure the integrity and parsability.
Another robustness enhancement could be via proper handling of the condition
when snapshot or transaction log cannot be completely written to disk.
Basically, better handling of write errors.
{noformat}
2013-08-28 12:05:30,732 ERROR [ZooKeeperServerMain] Unexpected exception,
exiting abnormally
java.io.EOFException
at java.io.DataInputStream.readInt(DataInputStream.java:375)
at
org.apache.jute.BinaryInputArchive.readInt(BinaryInputArchive.java:63)
at
org.apache.zookeeper.server.persistence.FileHeader.deserialize(FileHeader.java:64)
at
org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.inStreamCreated(FileTxnLog.java:558)
at
org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.createInputArchive(FileTxnLog.java:577)
at
org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.goToNextLog(FileTxnLog.java:543)
at
org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.next(FileTxnLog.java:625)
at
org.apache.zookeeper.server.persistence.FileTxnSnapLog.restore(FileTxnSnapLog.java:160)
at
org.apache.zookeeper.server.ZKDatabase.loadDataBase(ZKDatabase.java:223)
at
org.apache.zookeeper.server.ZooKeeperServer.loadData(ZooKeeperServer.java:250)
at
org.apache.zookeeper.server.ZooKeeperServer.startdata(ZooKeeperServer.java:383)
at
org.apache.zookeeper.server.NIOServerCnxnFactory.startup(NIOServerCnxnFactory.java:122)
at
org.apache.zookeeper.server.ZooKeeperServerMain.runFromConfig(ZooKeeperServerMain.java:112)
at
org.apache.zookeeper.server.ZooKeeperServerMain.initializeAndRun(ZooKeeperServerMain.java:86)
at
[jira] [Commented] (ZOOKEEPER-1747) Zookeeper server fails to start if transaction log file is corrupted
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13765472#comment-13765472
]
Sergey Maslyakov commented on ZOOKEEPER-1747:
-
Let me take my original statement about force-ignoring errors back. I think
Zookeeper server should handle data consistency issues gracefully. This means,
it needs to handle this type of errors as opposed to terminating. The reaction
to an error can be controlled by the user.
# For fatal errors, such as missing {{myid}} file, ZK server server shall exit.
# For non-fatal data consistency errors (empty log, missing epoch files, etc),
ZK can be instructed to:
## Come up empty
## Make best effort in restoring DataTree. If no data can be restored
consistently, ZK can be instructed to:
### Come up empty
### Exit
This way, a system operator, who is not a ZK expert, can be given a set of work
instruction on how to recover a failing ZK service.
Zookeeper server fails to start if transaction log file is corrupted
Key: ZOOKEEPER-1747
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1747
Project: ZooKeeper
Issue Type: Bug
Components: server
Affects Versions: 3.4.5
Environment: Solaris10/x86, Java 1.6
Reporter: Sergey Maslyakov
On multiple occasions when ZK was not able to write out a transaction log or
a snapshot file, the consequent attempt to restart the server fails. Usually
it happens when the underlying file system filled up; thus, preventing ZK
server from writing out consistent data file.
Upon start-up, the server reads in the snapshot and the transaction log. If
the deserializer fails and throws an exception, server terminates. Please see
the stack trace below.
Server not coming up for whatever reason is often an undesirable condition.
It would be nice to have an option to force-ignore parsing errors,
especially, in the transaction log. A check sum on the data could be a
possible solution to ensure the integrity and parsability.
Another robustness enhancement could be via proper handling of the condition
when snapshot or transaction log cannot be completely written to disk.
Basically, better handling of write errors.
{noformat}
2013-08-28 12:05:30,732 ERROR [ZooKeeperServerMain] Unexpected exception,
exiting abnormally
java.io.EOFException
at java.io.DataInputStream.readInt(DataInputStream.java:375)
at
org.apache.jute.BinaryInputArchive.readInt(BinaryInputArchive.java:63)
at
org.apache.zookeeper.server.persistence.FileHeader.deserialize(FileHeader.java:64)
at
org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.inStreamCreated(FileTxnLog.java:558)
at
org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.createInputArchive(FileTxnLog.java:577)
at
org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.goToNextLog(FileTxnLog.java:543)
at
org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.next(FileTxnLog.java:625)
at
org.apache.zookeeper.server.persistence.FileTxnSnapLog.restore(FileTxnSnapLog.java:160)
at
org.apache.zookeeper.server.ZKDatabase.loadDataBase(ZKDatabase.java:223)
at
org.apache.zookeeper.server.ZooKeeperServer.loadData(ZooKeeperServer.java:250)
at
org.apache.zookeeper.server.ZooKeeperServer.startdata(ZooKeeperServer.java:383)
at
org.apache.zookeeper.server.NIOServerCnxnFactory.startup(NIOServerCnxnFactory.java:122)
at
org.apache.zookeeper.server.ZooKeeperServerMain.runFromConfig(ZooKeeperServerMain.java:112)
at
org.apache.zookeeper.server.ZooKeeperServerMain.initializeAndRun(ZooKeeperServerMain.java:86)
at
org.apache.zookeeper.server.ZooKeeperServerMain.main(ZooKeeperServerMain.java:52)
at
org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:129)
at
org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:78)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (ZOOKEEPER-1747) Zookeeper server fails to start if transaction log file is corrupted
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Maslyakov resolved ZOOKEEPER-1747.
-
Resolution: Duplicate
Zookeeper server fails to start if transaction log file is corrupted
Key: ZOOKEEPER-1747
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1747
Project: ZooKeeper
Issue Type: Bug
Components: server
Affects Versions: 3.4.5
Environment: Solaris10/x86, Java 1.6
Reporter: Sergey Maslyakov
On multiple occasions when ZK was not able to write out a transaction log or
a snapshot file, the consequent attempt to restart the server fails. Usually
it happens when the underlying file system filled up; thus, preventing ZK
server from writing out consistent data file.
Upon start-up, the server reads in the snapshot and the transaction log. If
the deserializer fails and throws an exception, server terminates. Please see
the stack trace below.
Server not coming up for whatever reason is often an undesirable condition.
It would be nice to have an option to force-ignore parsing errors,
especially, in the transaction log. A check sum on the data could be a
possible solution to ensure the integrity and parsability.
Another robustness enhancement could be via proper handling of the condition
when snapshot or transaction log cannot be completely written to disk.
Basically, better handling of write errors.
{noformat}
2013-08-28 12:05:30,732 ERROR [ZooKeeperServerMain] Unexpected exception,
exiting abnormally
java.io.EOFException
at java.io.DataInputStream.readInt(DataInputStream.java:375)
at
org.apache.jute.BinaryInputArchive.readInt(BinaryInputArchive.java:63)
at
org.apache.zookeeper.server.persistence.FileHeader.deserialize(FileHeader.java:64)
at
org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.inStreamCreated(FileTxnLog.java:558)
at
org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.createInputArchive(FileTxnLog.java:577)
at
org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.goToNextLog(FileTxnLog.java:543)
at
org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.next(FileTxnLog.java:625)
at
org.apache.zookeeper.server.persistence.FileTxnSnapLog.restore(FileTxnSnapLog.java:160)
at
org.apache.zookeeper.server.ZKDatabase.loadDataBase(ZKDatabase.java:223)
at
org.apache.zookeeper.server.ZooKeeperServer.loadData(ZooKeeperServer.java:250)
at
org.apache.zookeeper.server.ZooKeeperServer.startdata(ZooKeeperServer.java:383)
at
org.apache.zookeeper.server.NIOServerCnxnFactory.startup(NIOServerCnxnFactory.java:122)
at
org.apache.zookeeper.server.ZooKeeperServerMain.runFromConfig(ZooKeeperServerMain.java:112)
at
org.apache.zookeeper.server.ZooKeeperServerMain.initializeAndRun(ZooKeeperServerMain.java:86)
at
org.apache.zookeeper.server.ZooKeeperServerMain.main(ZooKeeperServerMain.java:52)
at
org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:129)
at
org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:78)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1747) Zookeeper server fails to start if transaction log file is corrupted
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13765509#comment-13765509
]
Sergey Maslyakov commented on ZOOKEEPER-1747:
-
Yes, it is. Thank you for pointing this out. I marked this entry as a duplicate
of 1621.
Zookeeper server fails to start if transaction log file is corrupted
Key: ZOOKEEPER-1747
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1747
Project: ZooKeeper
Issue Type: Bug
Components: server
Affects Versions: 3.4.5
Environment: Solaris10/x86, Java 1.6
Reporter: Sergey Maslyakov
On multiple occasions when ZK was not able to write out a transaction log or
a snapshot file, the consequent attempt to restart the server fails. Usually
it happens when the underlying file system filled up; thus, preventing ZK
server from writing out consistent data file.
Upon start-up, the server reads in the snapshot and the transaction log. If
the deserializer fails and throws an exception, server terminates. Please see
the stack trace below.
Server not coming up for whatever reason is often an undesirable condition.
It would be nice to have an option to force-ignore parsing errors,
especially, in the transaction log. A check sum on the data could be a
possible solution to ensure the integrity and parsability.
Another robustness enhancement could be via proper handling of the condition
when snapshot or transaction log cannot be completely written to disk.
Basically, better handling of write errors.
{noformat}
2013-08-28 12:05:30,732 ERROR [ZooKeeperServerMain] Unexpected exception,
exiting abnormally
java.io.EOFException
at java.io.DataInputStream.readInt(DataInputStream.java:375)
at
org.apache.jute.BinaryInputArchive.readInt(BinaryInputArchive.java:63)
at
org.apache.zookeeper.server.persistence.FileHeader.deserialize(FileHeader.java:64)
at
org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.inStreamCreated(FileTxnLog.java:558)
at
org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.createInputArchive(FileTxnLog.java:577)
at
org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.goToNextLog(FileTxnLog.java:543)
at
org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.next(FileTxnLog.java:625)
at
org.apache.zookeeper.server.persistence.FileTxnSnapLog.restore(FileTxnSnapLog.java:160)
at
org.apache.zookeeper.server.ZKDatabase.loadDataBase(ZKDatabase.java:223)
at
org.apache.zookeeper.server.ZooKeeperServer.loadData(ZooKeeperServer.java:250)
at
org.apache.zookeeper.server.ZooKeeperServer.startdata(ZooKeeperServer.java:383)
at
org.apache.zookeeper.server.NIOServerCnxnFactory.startup(NIOServerCnxnFactory.java:122)
at
org.apache.zookeeper.server.ZooKeeperServerMain.runFromConfig(ZooKeeperServerMain.java:112)
at
org.apache.zookeeper.server.ZooKeeperServerMain.initializeAndRun(ZooKeeperServerMain.java:86)
at
org.apache.zookeeper.server.ZooKeeperServerMain.main(ZooKeeperServerMain.java:52)
at
org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:129)
at
org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:78)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1718) Support JLine 2
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13765679#comment-13765679 ] Michi Mutsuzaki commented on ZOOKEEPER-1718: Yes, it is. Thank you for pointing out, I wasn't aware of ZOOKEEPER-1655. I think I can apply ZOOKEEPER-1718 first and then merge ZOOKEEPER-1655 (i.e. keep the newer jline version from ZOOKEEPER-1718 and pick up the optional configuration stuff from ZOOKEEPER-1655). Support JLine 2 --- Key: ZOOKEEPER-1718 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1718 Project: ZooKeeper Issue Type: Test Reporter: Christopher Tubbs Priority: Critical Fix For: 3.5.0 Attachments: ZOOKEEPER-1718.patch not fixed -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1096) Leader communication should listen on specified IP, not wildcard address
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13765843#comment-13765843 ] Flavio Junqueira commented on ZOOKEEPER-1096: - Thanks for the patch. Here are a few comments: # Please add documentation. # Why are we using system properties and not the config file to set this up? # Please with parenthesis with if/else blocks, even if there is a single statement currently. # I don't find it very elegant to catch an exception to determine that we need to return false. Also, I'd rather not catch a generic exception, but instead catch the precise exception we are expecting in the case the property is not there. Leader communication should listen on specified IP, not wildcard address Key: ZOOKEEPER-1096 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1096 Project: ZooKeeper Issue Type: Improvement Components: server Affects Versions: 3.3.3, 3.4.0 Reporter: Jared Cantwell Assignee: Jared Cantwell Priority: Minor Fix For: 3.5.0, 3.4.6 Attachments: ZOOKEEPER-1096_branch3.4.patch, ZOOKEEPER-1096.patch, ZOOKEEPER-1096.patch, ZOOKEEPER-1096.patch Server should specify the local address that is used for leader communication and leader election (and not use the default of listening on all interfaces). This is similar to the clientPortAddress parameter that was added a year ago. After reviewing the code, we can't think of a reason why only the port would be used with the wildcard interface, when servers are already connecting specifically to that interface anyway. I have submitted a patch, but it does not account for all leader election algorithms. Probably should have an option to toggle this, for backwards compatibility, although it seems like it would be a bug if this change broke things. There is some more information about making it an option here: http://mail-archives.apache.org/mod_mbox/hadoop-zookeeper-dev/201008.mbox/%3CAANLkTikkT97Djqt3CU=h2+7gnj_4p28hgcxjh345h...@mail.gmail.com%3E -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1375) SendThread is exiting after OOMError
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13765965#comment-13765965
]
Keith Turner commented on ZOOKEEPER-1375:
-
In ACCUMULO-1708, I am trying to work out a way to make Accumulo server
processes die if any thread throws an Error. Accumulo uses Zookeeper and HDFS.
One problem I have run into is that zookeeper and HDFS create threads that
could possibly throw OOME. I thought I was onto something with
ThreadGroup.uncaughtException(), but since zookeeper and hdfs threads catch
Throwable its a dead end. If interested, I attached an example called
ThreadTest.java to ACCUMULO-1708 that shows an experiment trying to use a
thread group.
If zookeeper client side threads always rethrew Errors, then this would ideal
for my purposes. Zookeeper code could still try to take some action in catch.
I suppose this might look like the following.
{code:java}
try{
//...
} catch (Throwable e)
{
try{
//..
cleanup();
if(state.isAlive()){
eventThread.queueEvent(
new WatchedEvent(Event.EventType.None, Event.KeeperState.Disconnected,
null) )
}
//
}catch (Throwable e) {
//failure while trying to process failure
e.printStackTrace();
}finally{
throw e;
}
}
{code}
SendThread is exiting after OOMError
Key: ZOOKEEPER-1375
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1375
Project: ZooKeeper
Issue Type: Bug
Affects Versions: 3.4.0
Reporter: Rakesh R
After reviewing the ClientCnxn code, there is still chances of exiting the
SendThread without intimating the users. Say if client throws OOMError and
entered into the throwable block. Here again while sending the Disconnected
event, its creating new WatchedEvent() object.This will throw OOMError and
leads to exit the SendThread without any Disconnected event notification.
{noformat}
try{
//...
} catch (Throwable e)
{
//..
cleanup();
if(state.isAlive()){
eventThread.queueEvent(
new WatchedEvent(Event.EventType.None,
Event.KeeperState.Disconnected, null) )
}
//
}
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (ZOOKEEPER-1757) Adler32 may not be sufficient to protect aginst data corruption
Thawan Kooburat created ZOOKEEPER-1757: -- Summary: Adler32 may not be sufficient to protect aginst data corruption Key: ZOOKEEPER-1757 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1757 Project: ZooKeeper Issue Type: Bug Components: server Environment: Linux. Oracle JDK6/7 Reporter: Thawan Kooburat I was investigating data inconsistency bug in our internal branch. One possible area is snapshot/txnlog corruption. So I wrote a more robust corruption test and found that it is easy to break our checksum algorithm which is Adler32. When this happen, it is more likely that corrupted data will fail other sanity check during deserialization phase, but it is still scary that it can pass the checksum. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1757) Adler32 may not be sufficient to protect aginst data corruption
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thawan Kooburat updated ZOOKEEPER-1757: --- Attachment: TEST-org.apache.zookeeper.server.persistence.FileSnapTest.txt ZOOKEEPER.1757.patch Attached a test case that show the example of corrupted snapshot passed Adler32 check. I hard coded a seek value trigger this condition. On other environment, the value may have to change by using the random seek. In my case, I only need to do a few run to trigger a case that can bypass checksum. Also attached a sample log file from this unit test run. Adler32 may not be sufficient to protect aginst data corruption --- Key: ZOOKEEPER-1757 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1757 Project: ZooKeeper Issue Type: Bug Components: server Environment: Linux. Oracle JDK6/7 Reporter: Thawan Kooburat Attachments: TEST-org.apache.zookeeper.server.persistence.FileSnapTest.txt, ZOOKEEPER.1757.patch I was investigating data inconsistency bug in our internal branch. One possible area is snapshot/txnlog corruption. So I wrote a more robust corruption test and found that it is easy to break our checksum algorithm which is Adler32. When this happen, it is more likely that corrupted data will fail other sanity check during deserialization phase, but it is still scary that it can pass the checksum. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1757) Adler32 may not be sufficient to protect aginst data corruption
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13766058#comment-13766058 ] Hadoop QA commented on ZOOKEEPER-1757: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12602915/TEST-org.apache.zookeeper.server.persistence.FileSnapTest.txt against trunk revision 1522079. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 2 new or modified tests. -1 patch. The patch command could not apply the patch. Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1575//console This message is automatically generated. Adler32 may not be sufficient to protect aginst data corruption --- Key: ZOOKEEPER-1757 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1757 Project: ZooKeeper Issue Type: Bug Components: server Environment: Linux. Oracle JDK6/7 Reporter: Thawan Kooburat Attachments: TEST-org.apache.zookeeper.server.persistence.FileSnapTest.txt, ZOOKEEPER.1757.patch I was investigating data inconsistency bug in our internal branch. One possible area is snapshot/txnlog corruption. So I wrote a more robust corruption test and found that it is easy to break our checksum algorithm which is Adler32. When this happen, it is more likely that corrupted data will fail other sanity check during deserialization phase, but it is still scary that it can pass the checksum. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Failed: ZOOKEEPER-1757 PreCommit Build #1575
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1757 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1575/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 60 lines...] [exec] [exec] [exec] == [exec] == [exec] Applying patch. [exec] == [exec] == [exec] [exec] [exec] /usr/bin/patch: Only garbage was found in the patch input. [exec] PATCH APPLICATION FAILED [exec] [exec] [exec] [exec] [exec] -1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12602915/TEST-org.apache.zookeeper.server.persistence.FileSnapTest.txt [exec] against trunk revision 1522079. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 2 new or modified tests. [exec] [exec] -1 patch. The patch command could not apply the patch. [exec] [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1575//console [exec] [exec] This message is automatically generated. [exec] [exec] [exec] == [exec] == [exec] Adding comment to Jira. [exec] == [exec] == [exec] [exec] [exec] Comment added. [exec] 35533e76c862fe87caba08a1adfc89e9bdcf865b logged out [exec] [exec] [exec] == [exec] == [exec] Finished build. [exec] == [exec] == [exec] [exec] BUILD FAILED /home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/build.xml:1623: exec returned: 1 Total time: 42 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Description set: ZOOKEEPER-1757 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## No tests ran.
[jira] [Updated] (ZOOKEEPER-1757) Adler32 may not be sufficient to protect aginst data corruption
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thawan Kooburat updated ZOOKEEPER-1757: --- Attachment: (was: TEST-org.apache.zookeeper.server.persistence.FileSnapTest.txt) Adler32 may not be sufficient to protect aginst data corruption --- Key: ZOOKEEPER-1757 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1757 Project: ZooKeeper Issue Type: Bug Components: server Environment: Linux. Oracle JDK6/7 Reporter: Thawan Kooburat Attachments: ZOOKEEPER.1757.patch, ZOOKEEPER.1757.patch I was investigating data inconsistency bug in our internal branch. One possible area is snapshot/txnlog corruption. So I wrote a more robust corruption test and found that it is easy to break our checksum algorithm which is Adler32. When this happen, it is more likely that corrupted data will fail other sanity check during deserialization phase, but it is still scary that it can pass the checksum. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1757) Adler32 may not be sufficient to protect aginst data corruption
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thawan Kooburat updated ZOOKEEPER-1757: --- Attachment: ZOOKEEPER.1757.patch Re-upload the test case Adler32 may not be sufficient to protect aginst data corruption --- Key: ZOOKEEPER-1757 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1757 Project: ZooKeeper Issue Type: Bug Components: server Environment: Linux. Oracle JDK6/7 Reporter: Thawan Kooburat Attachments: ZOOKEEPER.1757.patch, ZOOKEEPER.1757.patch I was investigating data inconsistency bug in our internal branch. One possible area is snapshot/txnlog corruption. So I wrote a more robust corruption test and found that it is easy to break our checksum algorithm which is Adler32. When this happen, it is more likely that corrupted data will fail other sanity check during deserialization phase, but it is still scary that it can pass the checksum. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Bookkeeper 4.2.2 release candidate 0
Hi Jiannan, Could you send me the logs for this. The argLine in the pom has no affect here because that only applies to the surefire child process. This OOM is in the maven process itself, because the test is producing too many logs. I'll try reducing my heap to see if I can get the same to happen. -Ivan On Thu, Sep 12, 2013 at 03:31:19AM +, Jiannan Wang wrote: +1 for this release. All test cases pass except org.apache.bookkeeper.meta.GcLedgersTest, which throws following exception -- Exception in thread ThreadedStreamConsumer java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2882) at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:1 00) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390) at java.lang.StringBuffer.append(StringBuffer.java:224) at org.apache.maven.surefire.report.ConsoleOutputFileReporter.writeMessage(Con soleOutputFileReporter.java:115) at org.apache.maven.surefire.report.MulticastingReporter.writeMessage(Multicas tingReporter.java:101) at org.apache.maven.surefire.report.TestSetRunListener.writeTestOutput(TestSet RunListener.java:99) at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine (ForkClient.java:132) at org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer $Pumper.run(ThreadedStreamConsumer.java:67) at java.lang.Thread.run(Thread.java:680) -- I need to execute 'export MAVEN_OPTS=-Xmx1G' before running the test. (So the argLine-Xmx1G -Djava.net.preferIPv4Stack=true/argLine in pom.xml takes no effect? My maven version is Apache Maven 3.0.3 (r1075438; 2011-03-01 01:31:09+0800)) It's not a problem for the release, but I think maybe we can reduce annoying zk logs for this test to get around this problem. Best, Jiannan On 9/11/13 6:52 AM, Ivan Kelly iv...@apache.org wrote: This is the first release candidate for Apache Bookkeeper, version 4.2.2. This is a bugfix release for 4.2.1. There are some minor API improvements. Notably, it is now possible to check whether a ledger is closed without opening it, and it is now possible to get a list of ledgers available in the cluster. The full release notes is available at: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12324601st yleName=TextprojectId=12311293 *** Please download, test and vote by September 16th 2013, 10:00 UTC+0. *** Note that we are voting upon the source (tag), binaries are provided for convenience. Source and binary files: http://people.apache.org/~ivank/bookkeeper-4.2.2-candidate-0/ Maven staging repo: https://repository.apache.org/content/repositories/orgapachebookkeeper-025 / The tag to be voted upon: https://svn.apache.org/repos/asf/zookeeper/bookkeeper/tags/release-4.2.2 Bookkeeper's KEYS file containing PGP keys we use to sign the release: http://svn.apache.org/repos/asf/zookeeper/bookkeeper/dist/KEYS Please download the the source package, and follow the README to build and run a bookkeeper and hedwig service. -Ivan
Re: [VOTE] Bookkeeper 4.2.2 release candidate 0
I managed to repro with MAVEN_OPTS=-Xmx128M mvn test -Dtest=GcLedgersTest The test in question creates 3 ledgers, using asyncCreateLedgers, which causes a lot of zk INFO level log messages. This isn't an issue worth blocking the release for. -Ivan On Thu, Sep 12, 2013 at 09:42:49AM +, Ivan Kelly wrote: Hi Jiannan, Could you send me the logs for this. The argLine in the pom has no affect here because that only applies to the surefire child process. This OOM is in the maven process itself, because the test is producing too many logs. I'll try reducing my heap to see if I can get the same to happen. -Ivan On Thu, Sep 12, 2013 at 03:31:19AM +, Jiannan Wang wrote: +1 for this release. All test cases pass except org.apache.bookkeeper.meta.GcLedgersTest, which throws following exception -- Exception in thread ThreadedStreamConsumer java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2882) at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:1 00) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390) at java.lang.StringBuffer.append(StringBuffer.java:224) at org.apache.maven.surefire.report.ConsoleOutputFileReporter.writeMessage(Con soleOutputFileReporter.java:115) at org.apache.maven.surefire.report.MulticastingReporter.writeMessage(Multicas tingReporter.java:101) at org.apache.maven.surefire.report.TestSetRunListener.writeTestOutput(TestSet RunListener.java:99) at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine (ForkClient.java:132) at org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer $Pumper.run(ThreadedStreamConsumer.java:67) at java.lang.Thread.run(Thread.java:680) -- I need to execute 'export MAVEN_OPTS=-Xmx1G' before running the test. (So the argLine-Xmx1G -Djava.net.preferIPv4Stack=true/argLine in pom.xml takes no effect? My maven version is Apache Maven 3.0.3 (r1075438; 2011-03-01 01:31:09+0800)) It's not a problem for the release, but I think maybe we can reduce annoying zk logs for this test to get around this problem. Best, Jiannan On 9/11/13 6:52 AM, Ivan Kelly iv...@apache.org wrote: This is the first release candidate for Apache Bookkeeper, version 4.2.2. This is a bugfix release for 4.2.1. There are some minor API improvements. Notably, it is now possible to check whether a ledger is closed without opening it, and it is now possible to get a list of ledgers available in the cluster. The full release notes is available at: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12324601st yleName=TextprojectId=12311293 *** Please download, test and vote by September 16th 2013, 10:00 UTC+0. *** Note that we are voting upon the source (tag), binaries are provided for convenience. Source and binary files: http://people.apache.org/~ivank/bookkeeper-4.2.2-candidate-0/ Maven staging repo: https://repository.apache.org/content/repositories/orgapachebookkeeper-025 / The tag to be voted upon: https://svn.apache.org/repos/asf/zookeeper/bookkeeper/tags/release-4.2.2 Bookkeeper's KEYS file containing PGP keys we use to sign the release: http://svn.apache.org/repos/asf/zookeeper/bookkeeper/dist/KEYS Please download the the source package, and follow the README to build and run a bookkeeper and hedwig service. -Ivan
Re: [VOTE] Bookkeeper 4.2.2 release candidate 0
Hi Ivan, The log has been sent to your personal yahoo mail, please check it. Your explanation makes sense, thanks, Best, Jiannan On 9/12/13 5:42 PM, Ivan Kelly iv...@apache.org wrote: Hi Jiannan, Could you send me the logs for this. The argLine in the pom has no affect here because that only applies to the surefire child process. This OOM is in the maven process itself, because the test is producing too many logs. I'll try reducing my heap to see if I can get the same to happen. -Ivan On Thu, Sep 12, 2013 at 03:31:19AM +, Jiannan Wang wrote: +1 for this release. All test cases pass except org.apache.bookkeeper.meta.GcLedgersTest, which throws following exception -- Exception in thread ThreadedStreamConsumer java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2882) at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java :1 00) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390) at java.lang.StringBuffer.append(StringBuffer.java:224) at org.apache.maven.surefire.report.ConsoleOutputFileReporter.writeMessage(C on soleOutputFileReporter.java:115) at org.apache.maven.surefire.report.MulticastingReporter.writeMessage(Multic as tingReporter.java:101) at org.apache.maven.surefire.report.TestSetRunListener.writeTestOutput(TestS et RunListener.java:99) at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLi ne (ForkClient.java:132) at org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsum er $Pumper.run(ThreadedStreamConsumer.java:67) at java.lang.Thread.run(Thread.java:680) -- I need to execute 'export MAVEN_OPTS=-Xmx1G' before running the test. (So the argLine-Xmx1G -Djava.net.preferIPv4Stack=true/argLine in pom.xml takes no effect? My maven version is Apache Maven 3.0.3 (r1075438; 2011-03-01 01:31:09+0800)) It's not a problem for the release, but I think maybe we can reduce annoying zk logs for this test to get around this problem. Best, Jiannan On 9/11/13 6:52 AM, Ivan Kelly iv...@apache.org wrote: This is the first release candidate for Apache Bookkeeper, version 4.2.2. This is a bugfix release for 4.2.1. There are some minor API improvements. Notably, it is now possible to check whether a ledger is closed without opening it, and it is now possible to get a list of ledgers available in the cluster. The full release notes is available at: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12324601; st yleName=TextprojectId=12311293 *** Please download, test and vote by September 16th 2013, 10:00 UTC+0. *** Note that we are voting upon the source (tag), binaries are provided for convenience. Source and binary files: http://people.apache.org/~ivank/bookkeeper-4.2.2-candidate-0/ Maven staging repo: https://repository.apache.org/content/repositories/orgapachebookkeeper-0 25 / The tag to be voted upon: https://svn.apache.org/repos/asf/zookeeper/bookkeeper/tags/release-4.2.2 Bookkeeper's KEYS file containing PGP keys we use to sign the release: http://svn.apache.org/repos/asf/zookeeper/bookkeeper/dist/KEYS Please download the the source package, and follow the README to build and run a bookkeeper and hedwig service. -Ivan
