ZooKeeper-trunk-WinVS2008 - Build # 699 - Still Failing
See https://builds.apache.org/job/ZooKeeper-trunk-WinVS2008/699/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 109 lines...] generate_jute_parser: [mkdir] Created dir: f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008\trunk\build\jute_compiler\org\apache\jute\compiler\generated [ivy:artifactproperty] DEPRECATED: 'ivy.conf.file' is deprecated, use 'ivy.settings.file' instead [ivy:artifactproperty] :: loading settings :: file = f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008\trunk\ivysettings.xml [move] Moving 1 file to f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008\trunk\build\lib [javacc] Java Compiler Compiler Version 5.0 (Parser Generator) [javacc] (type javacc with no arguments for help) [javacc] Reading from file f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008\trunk\src\java\main\org\apache\jute\compiler\generated\rcc.jj . . . [javacc] File TokenMgrError.java does not exist. Will create one. [javacc] File ParseException.java does not exist. Will create one. [javacc] File Token.java does not exist. Will create one. [javacc] File SimpleCharStream.java does not exist. Will create one. [javacc] Parser generated successfully. jute: [javac] Compiling 39 source files to f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008\trunk\build\classes compile_jute_uptodate: compile_jute: [mkdir] Created dir: f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008\trunk\src\java\generated [mkdir] Created dir: f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008\trunk\src\c\generated [java] ../../zookeeper.jute Parsed Successfully [java] ../../zookeeper.jute Parsed Successfully [touch] Creating f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008\trunk\src\java\generated\.generated BUILD SUCCESSFUL Total time: 7 seconds [ZooKeeper-trunk-WinVS2008] $ cmd /c call C:\Users\hudson\AppData\Local\Temp\hudson648622084916031030.bat f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008set ZOOKEEPER_HOME=f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008\trunk f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008msbuild trunk/src/c/zookeeper.sln /p:Configuration=Release Microsoft (R) Build Engine Version 3.5.30729.1 [Microsoft .NET Framework, Version 2.0.50727.4223] Copyright (C) Microsoft Corporation 2007. All rights reserved. Build started 2/1/2013 8:31:16 AM. Project f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008\trunk\src\c\zookeeper.sln on node 0 (default targets). Building solution configuration Release|Win32. f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008\trunk\src\c\zookeeper.vcxproj(3,14): error MSB4066: The attribute Label in element ItemGroup is unrecognized. Done Building Project f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008\trunk\src\c\zookeeper.sln (default targets) -- FAILED. Build FAILED. f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008\trunk\src\c\zookeeper.sln (default target) (1) - (zookeeper target) - f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008\trunk\src\c\zookeeper.vcxproj(3,14): error MSB4066: The attribute Label in element ItemGroup is unrecognized. 0 Warning(s) 1 Error(s) Time Elapsed 00:00:09.38 f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008exit 1 Build step 'Execute Windows batch command' marked build as failure Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## No tests ran.
ZooKeeper-trunk-solaris - Build # 457 - Still Failing
See https://builds.apache.org/job/ZooKeeper-trunk-solaris/457/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 164977 lines...] [junit] 2013-02-01 09:00:21,243 [myid:] - INFO [NIOServerCxnFactory.SelectorThread-0:NIOServerCnxnFactory$SelectorThread@413] - selector thread exitted run method [junit] 2013-02-01 09:00:21,244 [myid:] - INFO [main:ZooKeeperServer@398] - shutting down [junit] 2013-02-01 09:00:21,244 [myid:] - INFO [main:SessionTrackerImpl@180] - Shutting down [junit] 2013-02-01 09:00:21,244 [myid:] - INFO [main:PrepRequestProcessor@804] - Shutting down [junit] 2013-02-01 09:00:21,245 [myid:] - INFO [main:SyncRequestProcessor@175] - Shutting down [junit] 2013-02-01 09:00:21,245 [myid:] - INFO [ProcessThread(sid:0 cport:-1)::PrepRequestProcessor@144] - PrepRequestProcessor exited loop! [junit] 2013-02-01 09:00:21,245 [myid:] - INFO [SyncThread:0:SyncRequestProcessor@155] - SyncRequestProcessor exited! [junit] 2013-02-01 09:00:21,245 [myid:] - INFO [main:FinalRequestProcessor@421] - shutdown of request processor complete [junit] 2013-02-01 09:00:21,246 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2013-02-01 09:00:21,246 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[] [junit] 2013-02-01 09:00:21,247 [myid:] - INFO [main:ClientBase@414] - STARTING server [junit] 2013-02-01 09:00:21,247 [myid:] - INFO [main:ZooKeeperServer@149] - Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 6 datadir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test2449905411248004643.junit.dir/version-2 snapdir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test2449905411248004643.junit.dir/version-2 [junit] 2013-02-01 09:00:21,248 [myid:] - INFO [main:NIOServerCnxnFactory@663] - Configuring NIO connection handler with 10s sessionless connection timeout, 2 selector thread(s), 16 worker threads, and 64 kB direct buffers. [junit] 2013-02-01 09:00:21,249 [myid:] - INFO [main:NIOServerCnxnFactory@676] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2013-02-01 09:00:21,250 [myid:] - INFO [main:FileSnap@83] - Reading snapshot /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test2449905411248004643.junit.dir/version-2/snapshot.b [junit] 2013-02-01 09:00:21,252 [myid:] - INFO [main:FileTxnSnapLog@270] - Snapshotting: 0xb to /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test2449905411248004643.junit.dir/version-2/snapshot.b [junit] 2013-02-01 09:00:21,253 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2013-02-01 09:00:21,254 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@289] - Accepted socket connection from /127.0.0.1:50582 [junit] 2013-02-01 09:00:21,255 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@829] - Processing stat command from /127.0.0.1:50582 [junit] 2013-02-01 09:00:21,255 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn$StatCommand@678] - Stat command output [junit] 2013-02-01 09:00:21,255 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@1000] - Closed socket connection for client /127.0.0.1:50582 (no session established for client) [junit] 2013-02-01 09:00:21,256 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[InMemoryDataTree, StandaloneServer_port] [junit] 2013-02-01 09:00:21,257 [myid:] - INFO [main:JMXEnv@105] - expect:InMemoryDataTree [junit] 2013-02-01 09:00:21,257 [myid:] - INFO [main:JMXEnv@108] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] 2013-02-01 09:00:21,257 [myid:] - INFO [main:JMXEnv@105] - expect:StandaloneServer_port [junit] 2013-02-01 09:00:21,257 [myid:] - INFO [main:JMXEnv@108] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2013-02-01 09:00:21,258 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@57] - FINISHED TEST METHOD testQuota [junit] 2013-02-01 09:00:21,258 [myid:] - INFO [main:ClientBase@451] - tearDown starting [junit] 2013-02-01 09:00:21,332 [myid:] - INFO [main:ZooKeeper@744] - Session: 0x13c94fc3068 closed [junit] 2013-02-01 09:00:21,332 [myid:] - INFO [main-EventThread:ClientCnxn$EventThread@511] - EventThread shut down [junit] 2013-02-01 09:00:21,332 [myid:] - INFO [main:ClientBase@421] - STOPPING server [junit] 2013-02-01 09:00:21,333 [myid:] - INFO
ZooKeeper-trunk - Build # 1820 - Failure
See https://builds.apache.org/job/ZooKeeper-trunk/1820/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 9811999 lines...] [junit] 2013-02-01 11:08:41,176 [myid:] - INFO [ProcessThread(sid:0 cport:-1)::PrepRequestProcessor@144] - PrepRequestProcessor exited loop! [junit] 2013-02-01 11:08:41,176 [myid:] - INFO [SyncThread:0:SyncRequestProcessor@155] - SyncRequestProcessor exited! [junit] 2013-02-01 11:08:41,177 [myid:] - INFO [main:FinalRequestProcessor@421] - shutdown of request processor complete [junit] 2013-02-01 11:08:41,177 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2013-02-01 11:08:41,178 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[] [junit] 2013-02-01 11:08:41,179 [myid:] - INFO [main:ClientBase@414] - STARTING server [junit] 2013-02-01 11:08:41,179 [myid:] - INFO [main:ZooKeeperServer@149] - Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 6 datadir /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk/trunk/build/test/tmp/test3808686541694216185.junit.dir/version-2 snapdir /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk/trunk/build/test/tmp/test3808686541694216185.junit.dir/version-2 [junit] 2013-02-01 11:08:41,180 [myid:] - INFO [main:NIOServerCnxnFactory@663] - Configuring NIO connection handler with 10s sessionless connection timeout, 2 selector thread(s), 16 worker threads, and 64 kB direct buffers. [junit] 2013-02-01 11:08:41,180 [myid:] - INFO [main:NIOServerCnxnFactory@676] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2013-02-01 11:08:41,181 [myid:] - INFO [main:FileSnap@83] - Reading snapshot /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk/trunk/build/test/tmp/test3808686541694216185.junit.dir/version-2/snapshot.b [junit] 2013-02-01 11:08:41,184 [myid:] - INFO [main:FileTxnSnapLog@270] - Snapshotting: 0xb to /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk/trunk/build/test/tmp/test3808686541694216185.junit.dir/version-2/snapshot.b [junit] 2013-02-01 11:08:41,186 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2013-02-01 11:08:41,186 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@289] - Accepted socket connection from /127.0.0.1:36423 [junit] 2013-02-01 11:08:41,187 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@829] - Processing stat command from /127.0.0.1:36423 [junit] 2013-02-01 11:08:41,187 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn$StatCommand@678] - Stat command output [junit] 2013-02-01 11:08:41,187 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@1000] - Closed socket connection for client /127.0.0.1:36423 (no session established for client) [junit] 2013-02-01 11:08:41,187 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[InMemoryDataTree, StandaloneServer_port] [junit] 2013-02-01 11:08:41,189 [myid:] - INFO [main:JMXEnv@105] - expect:InMemoryDataTree [junit] 2013-02-01 11:08:41,189 [myid:] - INFO [main:JMXEnv@108] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] 2013-02-01 11:08:41,189 [myid:] - INFO [main:JMXEnv@105] - expect:StandaloneServer_port [junit] 2013-02-01 11:08:41,189 [myid:] - INFO [main:JMXEnv@108] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2013-02-01 11:08:41,190 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@57] - FINISHED TEST METHOD testQuota [junit] 2013-02-01 11:08:41,190 [myid:] - INFO [main:ClientBase@451] - tearDown starting [junit] 2013-02-01 11:08:41,257 [myid:] - INFO [main:ZooKeeper@744] - Session: 0x13c9571ae61 closed [junit] 2013-02-01 11:08:41,257 [myid:] - INFO [main-EventThread:ClientCnxn$EventThread@511] - EventThread shut down [junit] 2013-02-01 11:08:41,257 [myid:] - INFO [main:ClientBase@421] - STOPPING server [junit] 2013-02-01 11:08:41,257 [myid:] - INFO [ConnnectionExpirer:NIOServerCnxnFactory$ConnectionExpirerThread@576] - ConnnectionExpirerThread interrupted [junit] 2013-02-01 11:08:41,258 [myid:] - INFO [NIOServerCxnFactory.SelectorThread-0:NIOServerCnxnFactory$SelectorThread@413] - selector thread exitted run method [junit] 2013-02-01 11:08:41,258 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@216] - accept thread exitted run method [junit] 2013-02-01 11:08:41,258 [myid:] - INFO [NIOServerCxnFactory.SelectorThread-1:NIOServerCnxnFactory$SelectorThread@413] - selector thread exitted run method [junit] 2013-02-01 11:08:41,258 [myid:] - INFO [main:ZooKeeperServer@398] - shutting down [junit] 2013-02-01 11:08:41,258 [myid:] - INFO
[jira] [Created] (ZOOKEEPER-1637) Intermittent Segfault with zkpython in pyzoo_exists
Robert Schultheis created ZOOKEEPER-1637:
Summary: Intermittent Segfault with zkpython in pyzoo_exists
Key: ZOOKEEPER-1637
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1637
Project: ZooKeeper
Issue Type: Bug
Affects Versions: 3.4.5, 3.4.4, 3.4.3
Reporter: Robert Schultheis
We are getting an intermittent segfault. This is OSX, zookeeper compiled using
brew. I've tried 3.4.3 - 3.4.5.
I used GDB to get the following backtrace:
{code}
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x
[Switching to process 10366 thread 0x1d03]
0x7fff8e0984f0 in strlen ()
(gdb) backtrace
#0 0x7fff8e0984f0 in strlen ()
#1 0x0001004983cc in prepend_string ()
#2 0x000100498451 in Request_path_init ()
#3 0x000100499e94 in zoo_awexists ()
#4 0x00010049a036 in zoo_wexists ()
#5 0x00010048170b in pyzoo_exists ()
#6 0x00010008c5d8 in PyEval_EvalFrameEx ()
#7 0x00010008ecd8 in PyEval_EvalCodeEx ()
#8 0x00010008ee6c in PyEval_EvalCode ()
#9 0x00010008be0a in PyEval_EvalFrameEx ()
#10 0x00010008ecd8 in PyEval_EvalCodeEx ()
#11 0x00010008ee6c in PyEval_EvalCode ()
#12 0x00010008be0a in PyEval_EvalFrameEx ()
#13 0x00010008ecd8 in PyEval_EvalCodeEx ()
#14 0x00010002cabf in PyClassMethod_New ()
#15 0x0001bd32 in PyObject_Call ()
#16 0x00010008c5ec in PyEval_EvalFrameEx ()
#17 0x00010008ecd8 in PyEval_EvalCodeEx ()
#18 0x00010002cabf in PyClassMethod_New ()
#19 0x0001bd32 in PyObject_Call ()
#20 0x00010001a6e9 in PyInstance_New ()
#21 0x0001bd32 in PyObject_Call ()
#22 0x000100055c5d in _PyObject_SlotCompare ()
#23 0x0001bd32 in PyObject_Call ()
#24 0x00010008bf63 in PyEval_EvalFrameEx ()
#25 0x00010008ecd8 in PyEval_EvalCodeEx ()
#26 0x00010008ee6c in PyEval_EvalCode ()
#27 0x00010008be0a in PyEval_EvalFrameEx ()
#28 0x00010008edf7 in PyEval_EvalCode ()
#29 0x00010008be0a in PyEval_EvalFrameEx ()
#30 0x00010008ecd8 in PyEval_EvalCodeEx ()
#31 0x00010002cabf in PyClassMethod_New ()
#32 0x0001bd32 in PyObject_Call ()
#33 0x00010001a6e9 in PyInstance_New ()
#34 0x0001bd32 in PyObject_Call ()
#35 0x000100087c40 in PyEval_CallObjectWithKeywords ()
#36 0x0001000b940d in initthread ()
#37 0x7fff8e0448bf in _pthread_start ()
#38 0x7fff8e047b75 in thread_start ()
{code}
--
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-1636) c-client crash when zoo_amulti failed
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thawan Kooburat updated ZOOKEEPER-1636: --- Attachment: ZOOKEEPER-1636.patch Fix code style and compile error c-client crash when zoo_amulti failed -- Key: ZOOKEEPER-1636 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1636 Project: ZooKeeper Issue Type: Bug Components: c client Affects Versions: 3.4.3 Reporter: Thawan Kooburat Assignee: Thawan Kooburat Priority: Critical Attachments: ZOOKEEPER-1636.patch, ZOOKEEPER-1636.patch, ZOOKEEPER-1636.patch deserialize_response for multi operation don't handle the case where the server fail to send back response. (Eg. when multi packet is too large) c-client will try to process completion of all sub-request as if the operation is successful and will eventually cause SIGSEGV -- 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-1624) PrepRequestProcessor abort multi-operation incorrectly
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thawan Kooburat updated ZOOKEEPER-1624:
---
Attachment: ZOOKEEPER-1624.patch
Clean up wait counter so that future test can run correctly
PrepRequestProcessor abort multi-operation incorrectly
--
Key: ZOOKEEPER-1624
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1624
Project: ZooKeeper
Issue Type: Bug
Components: server
Reporter: Thawan Kooburat
Assignee: Thawan Kooburat
Priority: Critical
Labels: zk-review
Fix For: 3.5.0
Attachments: ZOOKEEPER-1624.patch, ZOOKEEPER-1624.patch
We found this issue when trying to issue multiple instances of the following
multi-op concurrently
multi {
1. create sequential node /a-
2. create node /b
}
The expected result is that only the first multi-op request should success
and the rest of request should fail because /b is already exist
However, the reported result is that the subsequence multi-op failed because
of sequential node creation failed which is not possible.
Below is the return code for each sub-op when issuing 3 instances of the
above multi-op asynchronously
1. ZOK, ZOK
2. ZOK, ZNODEEXISTS,
3. ZNODEEXISTS, ZRUNTIMEINCONSISTENCY,
When I added more debug log. The cause is that PrepRequestProcessor rollback
outstandingChanges of the second multi-op incorrectly causing sequential node
name generation to be incorrect. Below is the sequential node name generated
by PrepRequestProcessor
1. create /a-0001
2. create /a-0003
3. create /a-0001
The bug is getPendingChanges() method. In failed to copied ChangeRecord for
the parent node (/). So rollbackPendingChanges() cannot restore the right
previous change record of the parent node when aborting the second multi-op
The impact of this bug is that sequential node creation on the same parent
node may fail until the previous one is committed. I am not sure if there is
other implication or not.
--
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-1624) PrepRequestProcessor abort multi-operation incorrectly
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13569121#comment-13569121
]
Thawan Kooburat commented on ZOOKEEPER-1624:
It should be simple to replicate if ZOOKEEPER-1572 is committed to trunk. We
just need async functionality to test this.
PrepRequestProcessor abort multi-operation incorrectly
--
Key: ZOOKEEPER-1624
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1624
Project: ZooKeeper
Issue Type: Bug
Components: server
Reporter: Thawan Kooburat
Assignee: Thawan Kooburat
Priority: Critical
Labels: zk-review
Fix For: 3.5.0
Attachments: ZOOKEEPER-1624.patch, ZOOKEEPER-1624.patch
We found this issue when trying to issue multiple instances of the following
multi-op concurrently
multi {
1. create sequential node /a-
2. create node /b
}
The expected result is that only the first multi-op request should success
and the rest of request should fail because /b is already exist
However, the reported result is that the subsequence multi-op failed because
of sequential node creation failed which is not possible.
Below is the return code for each sub-op when issuing 3 instances of the
above multi-op asynchronously
1. ZOK, ZOK
2. ZOK, ZNODEEXISTS,
3. ZNODEEXISTS, ZRUNTIMEINCONSISTENCY,
When I added more debug log. The cause is that PrepRequestProcessor rollback
outstandingChanges of the second multi-op incorrectly causing sequential node
name generation to be incorrect. Below is the sequential node name generated
by PrepRequestProcessor
1. create /a-0001
2. create /a-0003
3. create /a-0001
The bug is getPendingChanges() method. In failed to copied ChangeRecord for
the parent node (/). So rollbackPendingChanges() cannot restore the right
previous change record of the parent node when aborting the second multi-op
The impact of this bug is that sequential node creation on the same parent
node may fail until the previous one is committed. I am not sure if there is
other implication or not.
--
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
async multi requests in the Java client
Can anyone jog my memory about why we didn't implement multi requests with async callbacks for the Java client like we did in the C client? I think it's not a great precedent to set because now we have bugs that have been discovered in the implementation of multi on the server side that are easily reproducible only via the C client, see: https://issues.apache.org/jira/browse/ZOOKEEPER-1624 Multi was a big project so I can understand why we let this go for the first impl, but unless there's a technical reason not to support it in the Java client it would be a good fix for us to put it in there as well, especially in light of this issue. Thoughts? C
Re: async multi requests in the Java client
Thawan's followup on that ticket pointed me to this open issue: https://issues.apache.org/jira/browse/ZOOKEEPER-1572 So that resolves it, which is great. My general call-out on divergent functionality away from the Java client stands for future reference but looks like we're good for this one. C On Fri, Feb 1, 2013 at 4:42 PM, Camille Fournier cami...@apache.org wrote: Can anyone jog my memory about why we didn't implement multi requests with async callbacks for the Java client like we did in the C client? I think it's not a great precedent to set because now we have bugs that have been discovered in the implementation of multi on the server side that are easily reproducible only via the C client, see: https://issues.apache.org/jira/browse/ZOOKEEPER-1624 Multi was a big project so I can understand why we let this go for the first impl, but unless there's a technical reason not to support it in the Java client it would be a good fix for us to put it in there as well, especially in light of this issue. Thoughts? C
Failed: ZOOKEEPER-1636 PreCommit Build #1374
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1636 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1374/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 270482 lines...] [exec] [exec] [exec] -1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12567637/ZOOKEEPER-1636.patch [exec] against trunk revision 1438375. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 3 new or modified tests. [exec] [exec] +1 javadoc. The javadoc tool did not generate any warning messages. [exec] [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings. [exec] [exec] +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. [exec] [exec] -1 release audit. The applied patch generated 26 release audit warnings (more than the trunk's current 24 warnings). [exec] [exec] +1 core tests. The patch passed core unit tests. [exec] [exec] +1 contrib tests. The patch passed contrib unit tests. [exec] [exec] Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1374//testReport/ [exec] Release audit warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1374//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1374//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1374//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] 6fc751f9f817406b721f6a975d26e6cc8115c813 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: 28 minutes 36 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Description set: ZOOKEEPER-1636 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## All tests passed
[jira] [Commented] (ZOOKEEPER-1636) c-client crash when zoo_amulti failed
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13569133#comment-13569133 ] Hadoop QA commented on ZOOKEEPER-1636: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12567637/ZOOKEEPER-1636.patch against trunk revision 1438375. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. -1 release audit. The applied patch generated 26 release audit warnings (more than the trunk's current 24 warnings). +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1374//testReport/ Release audit warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1374//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1374//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1374//console This message is automatically generated. c-client crash when zoo_amulti failed -- Key: ZOOKEEPER-1636 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1636 Project: ZooKeeper Issue Type: Bug Components: c client Affects Versions: 3.4.3 Reporter: Thawan Kooburat Assignee: Thawan Kooburat Priority: Critical Attachments: ZOOKEEPER-1636.patch, ZOOKEEPER-1636.patch, ZOOKEEPER-1636.patch deserialize_response for multi operation don't handle the case where the server fail to send back response. (Eg. when multi packet is too large) c-client will try to process completion of all sub-request as if the operation is successful and will eventually cause SIGSEGV -- 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-1624) PrepRequestProcessor abort multi-operation incorrectly
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13569136#comment-13569136
]
Camille Fournier commented on ZOOKEEPER-1624:
-
Oh that's great Thawan, I will see about getting 1572 committed so we can get
an easy Java-side test for this bug.
PrepRequestProcessor abort multi-operation incorrectly
--
Key: ZOOKEEPER-1624
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1624
Project: ZooKeeper
Issue Type: Bug
Components: server
Reporter: Thawan Kooburat
Assignee: Thawan Kooburat
Priority: Critical
Labels: zk-review
Fix For: 3.5.0
Attachments: ZOOKEEPER-1624.patch, ZOOKEEPER-1624.patch
We found this issue when trying to issue multiple instances of the following
multi-op concurrently
multi {
1. create sequential node /a-
2. create node /b
}
The expected result is that only the first multi-op request should success
and the rest of request should fail because /b is already exist
However, the reported result is that the subsequence multi-op failed because
of sequential node creation failed which is not possible.
Below is the return code for each sub-op when issuing 3 instances of the
above multi-op asynchronously
1. ZOK, ZOK
2. ZOK, ZNODEEXISTS,
3. ZNODEEXISTS, ZRUNTIMEINCONSISTENCY,
When I added more debug log. The cause is that PrepRequestProcessor rollback
outstandingChanges of the second multi-op incorrectly causing sequential node
name generation to be incorrect. Below is the sequential node name generated
by PrepRequestProcessor
1. create /a-0001
2. create /a-0003
3. create /a-0001
The bug is getPendingChanges() method. In failed to copied ChangeRecord for
the parent node (/). So rollbackPendingChanges() cannot restore the right
previous change record of the parent node when aborting the second multi-op
The impact of this bug is that sequential node creation on the same parent
node may fail until the previous one is committed. I am not sure if there is
other implication or not.
--
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-1624) PrepRequestProcessor abort multi-operation incorrectly
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13569138#comment-13569138
]
Ted Yu commented on ZOOKEEPER-1624:
---
The fix would be backported to 3.4, right ?
PrepRequestProcessor abort multi-operation incorrectly
--
Key: ZOOKEEPER-1624
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1624
Project: ZooKeeper
Issue Type: Bug
Components: server
Reporter: Thawan Kooburat
Assignee: Thawan Kooburat
Priority: Critical
Labels: zk-review
Fix For: 3.5.0
Attachments: ZOOKEEPER-1624.patch, ZOOKEEPER-1624.patch
We found this issue when trying to issue multiple instances of the following
multi-op concurrently
multi {
1. create sequential node /a-
2. create node /b
}
The expected result is that only the first multi-op request should success
and the rest of request should fail because /b is already exist
However, the reported result is that the subsequence multi-op failed because
of sequential node creation failed which is not possible.
Below is the return code for each sub-op when issuing 3 instances of the
above multi-op asynchronously
1. ZOK, ZOK
2. ZOK, ZNODEEXISTS,
3. ZNODEEXISTS, ZRUNTIMEINCONSISTENCY,
When I added more debug log. The cause is that PrepRequestProcessor rollback
outstandingChanges of the second multi-op incorrectly causing sequential node
name generation to be incorrect. Below is the sequential node name generated
by PrepRequestProcessor
1. create /a-0001
2. create /a-0003
3. create /a-0001
The bug is getPendingChanges() method. In failed to copied ChangeRecord for
the parent node (/). So rollbackPendingChanges() cannot restore the right
previous change record of the parent node when aborting the second multi-op
The impact of this bug is that sequential node creation on the same parent
node may fail until the previous one is committed. I am not sure if there is
other implication or not.
--
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-1624 PreCommit Build #1375
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1624 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1375/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 270369 lines...] [exec] [exec] [exec] -1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12567638/ZOOKEEPER-1624.patch [exec] against trunk revision 1438375. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 3 new or modified tests. [exec] [exec] +1 javadoc. The javadoc tool did not generate any warning messages. [exec] [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings. [exec] [exec] +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. [exec] [exec] -1 release audit. The applied patch generated 26 release audit warnings (more than the trunk's current 24 warnings). [exec] [exec] +1 core tests. The patch passed core unit tests. [exec] [exec] +1 contrib tests. The patch passed contrib unit tests. [exec] [exec] Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1375//testReport/ [exec] Release audit warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1375//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1375//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1375//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] b4be329c6d9e468853caa63555f52f4533b1c5c5 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: 27 minutes 58 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Description set: ZOOKEEPER-1624 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## All tests passed
[jira] [Commented] (ZOOKEEPER-1624) PrepRequestProcessor abort multi-operation incorrectly
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13569147#comment-13569147
]
Hadoop QA commented on ZOOKEEPER-1624:
--
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12567638/ZOOKEEPER-1624.patch
against trunk revision 1438375.
+1 @author. The patch does not contain any @author tags.
+1 tests included. The patch appears to include 3 new or modified tests.
+1 javadoc. The javadoc tool did not generate any warning messages.
+1 javac. The applied patch does not increase the total number of javac
compiler warnings.
+1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9)
warnings.
-1 release audit. The applied patch generated 26 release audit warnings
(more than the trunk's current 24 warnings).
+1 core tests. The patch passed core unit tests.
+1 contrib tests. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1375//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1375//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
Findbugs warnings:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1375//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1375//console
This message is automatically generated.
PrepRequestProcessor abort multi-operation incorrectly
--
Key: ZOOKEEPER-1624
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1624
Project: ZooKeeper
Issue Type: Bug
Components: server
Reporter: Thawan Kooburat
Assignee: Thawan Kooburat
Priority: Critical
Labels: zk-review
Fix For: 3.5.0
Attachments: ZOOKEEPER-1624.patch, ZOOKEEPER-1624.patch
We found this issue when trying to issue multiple instances of the following
multi-op concurrently
multi {
1. create sequential node /a-
2. create node /b
}
The expected result is that only the first multi-op request should success
and the rest of request should fail because /b is already exist
However, the reported result is that the subsequence multi-op failed because
of sequential node creation failed which is not possible.
Below is the return code for each sub-op when issuing 3 instances of the
above multi-op asynchronously
1. ZOK, ZOK
2. ZOK, ZNODEEXISTS,
3. ZNODEEXISTS, ZRUNTIMEINCONSISTENCY,
When I added more debug log. The cause is that PrepRequestProcessor rollback
outstandingChanges of the second multi-op incorrectly causing sequential node
name generation to be incorrect. Below is the sequential node name generated
by PrepRequestProcessor
1. create /a-0001
2. create /a-0003
3. create /a-0001
The bug is getPendingChanges() method. In failed to copied ChangeRecord for
the parent node (/). So rollbackPendingChanges() cannot restore the right
previous change record of the parent node when aborting the second multi-op
The impact of this bug is that sequential node creation on the same parent
node may fail until the previous one is committed. I am not sure if there is
other implication or not.
--
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: async multi requests in the Java client
As far as I know it was not intentional. My best guess here is that is was due to different people working on different parts of Multi. Ted did the original Java client work but didn't have the time to do the C client work and my company really needed that functionality so I volunteered to implement it. We never discussed the async interface. I only implemented it because the C client necessitates it. All of the synchronous interfaces are just wrappers around the asynchronous ones. I think this was definitely an oversight. At a minimum it seems during the many code reviews the Multi code got this should have been noticed.. On Fri, Feb 1, 2013 at 2:45 PM, Camille Fournier cami...@apache.org wrote: Thawan's followup on that ticket pointed me to this open issue: https://issues.apache.org/jira/browse/ZOOKEEPER-1572 So that resolves it, which is great. My general call-out on divergent functionality away from the Java client stands for future reference but looks like we're good for this one. C On Fri, Feb 1, 2013 at 4:42 PM, Camille Fournier cami...@apache.org wrote: Can anyone jog my memory about why we didn't implement multi requests with async callbacks for the Java client like we did in the C client? I think it's not a great precedent to set because now we have bugs that have been discovered in the implementation of multi on the server side that are easily reproducible only via the C client, see: https://issues.apache.org/jira/browse/ZOOKEEPER-1624 Multi was a big project so I can understand why we let this go for the first impl, but unless there's a technical reason not to support it in the Java client it would be a good fix for us to put it in there as well, especially in light of this issue. Thoughts? C
[jira] [Updated] (ZOOKEEPER-1624) PrepRequestProcessor abort multi-operation incorrectly
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Hunt updated ZOOKEEPER-1624:
Fix Version/s: 3.4.6
PrepRequestProcessor abort multi-operation incorrectly
--
Key: ZOOKEEPER-1624
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1624
Project: ZooKeeper
Issue Type: Bug
Components: server
Reporter: Thawan Kooburat
Assignee: Thawan Kooburat
Priority: Critical
Labels: zk-review
Fix For: 3.5.0, 3.4.6
Attachments: ZOOKEEPER-1624.patch, ZOOKEEPER-1624.patch
We found this issue when trying to issue multiple instances of the following
multi-op concurrently
multi {
1. create sequential node /a-
2. create node /b
}
The expected result is that only the first multi-op request should success
and the rest of request should fail because /b is already exist
However, the reported result is that the subsequence multi-op failed because
of sequential node creation failed which is not possible.
Below is the return code for each sub-op when issuing 3 instances of the
above multi-op asynchronously
1. ZOK, ZOK
2. ZOK, ZNODEEXISTS,
3. ZNODEEXISTS, ZRUNTIMEINCONSISTENCY,
When I added more debug log. The cause is that PrepRequestProcessor rollback
outstandingChanges of the second multi-op incorrectly causing sequential node
name generation to be incorrect. Below is the sequential node name generated
by PrepRequestProcessor
1. create /a-0001
2. create /a-0003
3. create /a-0001
The bug is getPendingChanges() method. In failed to copied ChangeRecord for
the parent node (/). So rollbackPendingChanges() cannot restore the right
previous change record of the parent node when aborting the second multi-op
The impact of this bug is that sequential node creation on the same parent
node may fail until the previous one is committed. I am not sure if there is
other implication or not.
--
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-1572) Add an async interface for multi request
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Camille Fournier updated ZOOKEEPER-1572: Attachment: ZOOKEEPER-1572.patch Add an async interface for multi request Key: ZOOKEEPER-1572 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1572 Project: ZooKeeper Issue Type: Improvement Components: java client Affects Versions: 3.4.5 Reporter: Sijie Guo Assignee: Sijie Guo Labels: review Fix For: 3.5.0 Attachments: ZOOKEEPER-1572.diff, ZOOKEEPER-1572.diff, ZOOKEEPER-1572.patch Currently there is no async interface for multi request in ZooKeeper java client. -- 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-1572) Add an async interface for multi request
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13569218#comment-13569218 ] Camille Fournier commented on ZOOKEEPER-1572: - Uploading a patch that applies cleanly to trunk Add an async interface for multi request Key: ZOOKEEPER-1572 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1572 Project: ZooKeeper Issue Type: Improvement Components: java client Affects Versions: 3.4.5 Reporter: Sijie Guo Assignee: Sijie Guo Labels: review Fix For: 3.5.0 Attachments: ZOOKEEPER-1572.diff, ZOOKEEPER-1572.diff, ZOOKEEPER-1572.patch Currently there is no async interface for multi request in ZooKeeper java client. -- 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-1572 PreCommit Build #1376
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1572 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1376/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 270300 lines...] [exec] [exec] [exec] -1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12567658/ZOOKEEPER-1572.patch [exec] against trunk revision 1438375. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 3 new or modified tests. [exec] [exec] +1 javadoc. The javadoc tool did not generate any warning messages. [exec] [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings. [exec] [exec] +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. [exec] [exec] -1 release audit. The applied patch generated 26 release audit warnings (more than the trunk's current 24 warnings). [exec] [exec] +1 core tests. The patch passed core unit tests. [exec] [exec] +1 contrib tests. The patch passed contrib unit tests. [exec] [exec] Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1376//testReport/ [exec] Release audit warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1376//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1376//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1376//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] 565e962280e98e7b7a2a9854e7e6f5b1d81872e4 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: 28 minutes 10 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Description set: ZOOKEEPER-1572 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## All tests passed
[jira] [Updated] (ZOOKEEPER-1635) Support x64 architecture for Windows
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Gutierrez updated ZOOKEEPER-1635:
---
Fix Version/s: 3.5.0
Support x64 architecture for Windows
Key: ZOOKEEPER-1635
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1635
Project: ZooKeeper
Issue Type: Improvement
Environment: Windows x64 systems.
Reporter: Tomas Gutierrez
Fix For: 3.5.0
x64 target does not support _asm inline (See:
http://msdn.microsoft.com/en-us/library/4ks26t93(v=vs.80).aspx)
The proposal is to use native windows function which still valid for i386 and
x64 architecture.
In order to avoid any potential break, a compilation directive has been
added. But, the best should be the removal of the asm part.
---
sample code
---
int32_t fetch_and_add(volatile int32_t* operand, int incr)
{
#ifndef WIN32
int32_t result;
asm __volatile__(
lock xaddl %0,%1\n
: =r(result), =m(*(int *)operand)
: 0(incr)
: memory);
return result;
#else
#ifdef WIN32_NOASM
InterlockedExchangeAdd(operand, incr);
return *operand;
#else
volatile int32_t result;
_asm
{
mov eax, operand; //eax = v;
mov ebx, incr; // ebx = i;
mov ecx, 0x0; // ecx = 0;
lock xadd dword ptr [eax], ecx;
lock xadd dword ptr [eax], ebx;
mov result, ecx; // result = ebx;
}
return result;*/
#endif
#endif
}
--
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: async multi requests in the Java client
Yeah. It was an oversight. I did the java client and I ten not to think much about the asynchronous interfaces so I never designed anything along those lines. Should be hard to add. Sent from my iPhone On Feb 1, 2013, at 2:04 PM, Marshall McMullen marshall.mcmul...@gmail.com wrote: As far as I know it was not intentional. My best guess here is that is was due to different people working on different parts of Multi. Ted did the original Java client work but didn't have the time to do the C client work and my company really needed that functionality so I volunteered to implement it. We never discussed the async interface. I only implemented it because the C client necessitates it. All of the synchronous interfaces are just wrappers around the asynchronous ones. I think this was definitely an oversight. At a minimum it seems during the many code reviews the Multi code got this should have been noticed.. On Fri, Feb 1, 2013 at 2:45 PM, Camille Fournier cami...@apache.org wrote: Thawan's followup on that ticket pointed me to this open issue: https://issues.apache.org/jira/browse/ZOOKEEPER-1572 So that resolves it, which is great. My general call-out on divergent functionality away from the Java client stands for future reference but looks like we're good for this one. C On Fri, Feb 1, 2013 at 4:42 PM, Camille Fournier cami...@apache.org wrote: Can anyone jog my memory about why we didn't implement multi requests with async callbacks for the Java client like we did in the C client? I think it's not a great precedent to set because now we have bugs that have been discovered in the implementation of multi on the server side that are easily reproducible only via the C client, see: https://issues.apache.org/jira/browse/ZOOKEEPER-1624 Multi was a big project so I can understand why we let this go for the first impl, but unless there's a technical reason not to support it in the Java client it would be a good fix for us to put it in there as well, especially in light of this issue. Thoughts? C
Build failed in Jenkins: bookkeeper-trunk #84
See https://builds.apache.org/job/bookkeeper-trunk/84/ -- [...truncated 894 lines...] [INFO] Copying junit-4.8.1.jar to https://builds.apache.org/job/bookkeeper-trunk/ws/hedwig-server/lib/junit-4.8.1.jar [INFO] Copying log4j-1.2.15.jar to https://builds.apache.org/job/bookkeeper-trunk/ws/hedwig-server/lib/log4j-1.2.15.jar [INFO] Copying bookkeeper-server-4.3.0-SNAPSHOT.jar to https://builds.apache.org/job/bookkeeper-trunk/ws/hedwig-server/lib/bookkeeper-server-4.3.0-SNAPSHOT.jar [INFO] Copying bookkeeper-server-4.3.0-SNAPSHOT-tests.jar to https://builds.apache.org/job/bookkeeper-trunk/ws/hedwig-server/lib/bookkeeper-server-4.3.0-SNAPSHOT-tests.jar [INFO] Copying hedwig-client-4.3.0-SNAPSHOT.jar to https://builds.apache.org/job/bookkeeper-trunk/ws/hedwig-server/lib/hedwig-client-4.3.0-SNAPSHOT.jar [INFO] Copying hedwig-protocol-4.3.0-SNAPSHOT.jar to https://builds.apache.org/job/bookkeeper-trunk/ws/hedwig-server/lib/hedwig-protocol-4.3.0-SNAPSHOT.jar [INFO] Copying hedwig-server-compat400-4.0.0.jar to https://builds.apache.org/job/bookkeeper-trunk/ws/hedwig-server/lib/hedwig-server-compat400-4.0.0.jar [INFO] Copying hedwig-server-compat410-4.1.0.jar to https://builds.apache.org/job/bookkeeper-trunk/ws/hedwig-server/lib/hedwig-server-compat410-4.1.0.jar [INFO] Copying derby-10.8.2.2.jar to https://builds.apache.org/job/bookkeeper-trunk/ws/hedwig-server/lib/derby-10.8.2.2.jar [INFO] Copying zookeeper-3.4.3.jar to https://builds.apache.org/job/bookkeeper-trunk/ws/hedwig-server/lib/zookeeper-3.4.3.jar [INFO] Copying zookeeper-3.4.3-tests.jar to https://builds.apache.org/job/bookkeeper-trunk/ws/hedwig-server/lib/zookeeper-3.4.3-tests.jar [INFO] Copying netty-3.2.4.Final.jar to https://builds.apache.org/job/bookkeeper-trunk/ws/hedwig-server/lib/netty-3.2.4.Final.jar [INFO] Copying slf4j-api-1.6.4.jar to https://builds.apache.org/job/bookkeeper-trunk/ws/hedwig-server/lib/slf4j-api-1.6.4.jar [INFO] Copying slf4j-log4j12-1.6.4.jar to https://builds.apache.org/job/bookkeeper-trunk/ws/hedwig-server/lib/slf4j-log4j12-1.6.4.jar [INFO] [INFO] --- maven-jar-plugin:2.3.1:test-jar (default) @ hedwig-server --- [INFO] Building jar: https://builds.apache.org/job/bookkeeper-trunk/ws/hedwig-server/target/hedwig-server-4.3.0-SNAPSHOT-tests.jar [INFO] [INFO] findbugs-maven-plugin:2.3.2:check (default-cli) @ hedwig-server [INFO] [INFO] --- findbugs-maven-plugin:2.3.2:findbugs (findbugs) @ hedwig-server --- [INFO] ** FindBugsMojo execute *** [INFO] canGenerate is true [INFO] ** FindBugsMojo executeFindbugs *** [INFO] Temp File is https://builds.apache.org/job/bookkeeper-trunk/ws/hedwig-server/target/findbugsTemp.xml [INFO] Fork Value is true [INFO] xmlOutput is false [INFO] [INFO] findbugs-maven-plugin:2.3.2:check (default-cli) @ hedwig-server [INFO] [INFO] --- findbugs-maven-plugin:2.3.2:check (default-cli) @ hedwig-server --- [INFO] BugInstance size is 0 [INFO] Error size is 0 [INFO] [INFO] [INFO] Building bookkeeper-benchmark 4.3.0-SNAPSHOT [INFO] [INFO] [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ bookkeeper-benchmark --- [INFO] [INFO] --- apache-rat-plugin:0.7:check (default-cli) @ bookkeeper-benchmark --- [INFO] Exclude: .git/**/* [INFO] Exclude: **/.svn/**/* [INFO] Exclude: CHANGES.txt [INFO] Exclude: **/README [INFO] Exclude: **/apidocs/* [INFO] Exclude: test-patch/**/* [INFO] [INFO] --- maven-remote-resources-plugin:1.1:process (default) @ bookkeeper-benchmark --- [INFO] [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ bookkeeper-benchmark --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory https://builds.apache.org/job/bookkeeper-trunk/ws/bookkeeper-benchmark/src/main/resources [INFO] Copying 3 resources [INFO] [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ bookkeeper-benchmark --- [INFO] Compiling 5 source files to https://builds.apache.org/job/bookkeeper-trunk/ws/bookkeeper-benchmark/target/classes [INFO] [INFO] --- maven-resources-plugin:2.4.3:testResources (default-testResources) @ bookkeeper-benchmark --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] Copying 1 resource [INFO] Copying 3 resources [INFO] [INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @ bookkeeper-benchmark --- [INFO] Compiling 1 source file to https://builds.apache.org/job/bookkeeper-trunk/ws/bookkeeper-benchmark/target/test-classes [INFO] [INFO] --- maven-surefire-plugin:2.9:test (default-test) @ bookkeeper-benchmark --- [INFO] Surefire report directory: https://builds.apache.org/job/bookkeeper-trunk/ws/bookkeeper-benchmark/target/surefire-reports
