[
https://issues.apache.org/jira/browse/ZOOKEEPER-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13028580#comment-13028580
]
Marshall McMullen commented on ZOOKEEPER-965:
---------------------------------------------
Additional debugging... Note that as zk server is coming up it's reading in a
snapshot:
2011-05-03 22:14:16,872 [myid:] - INFO [main:Environment@98] - Server
environment:java.io.tmpdir=/tmp
2011-05-03 22:14:16,872 [myid:] - INFO [main:Environment@98] - Server
environment:java.compiler=<NA>
2011-05-03 22:14:16,872 [myid:] - INFO [main:Environment@98] - Server
environment:os.name=Linux
2011-05-03 22:14:16,873 [myid:] - INFO [main:Environment@98] - Server
environment:os.arch=amd64
2011-05-03 22:14:16,873 [myid:] - INFO [main:Environment@98] - Server
environment:os.version=2.6.37-gentoo-r4
2011-05-03 22:14:16,874 [myid:] - INFO [main:Environment@98] - Server
environment:user.name=marshall
2011-05-03 22:14:16,874 [myid:] - INFO [main:Environment@98] - Server
environment:user.home=/home/marshall
2011-05-03 22:14:16,875 [myid:] - INFO [main:Environment@98] - Server
environment:user.dir=/home/marshall/zookeeper-multi/src/c
2011-05-03 22:14:16,880 [myid:] - INFO [main:ZooKeeperServer@713] - tickTime
set to 3000
2011-05-03 22:14:16,881 [myid:] - INFO [main:ZooKeeperServer@722] -
minSessionTimeout set to -1
2011-05-03 22:14:16,881 [myid:] - INFO [main:ZooKeeperServer@731] -
maxSessionTimeout set to -1
2011-05-03 22:14:16,899 [myid:] - INFO [main:NIOServerCnxnFactory@94] -
binding to port 0.0.0.0/0.0.0.0:22181
2011-05-03 22:14:16,916 [myid:] - INFO [main:FileSnap@83] - Reading snapshot
/tmp/zkdata/version-2/snapshot.0
2011-05-03 22:14:16,927 [myid:] - INFO [main:FileTxnSnapLog@186] - >>
PROCESSING HDR=85490560384172033,1304482428,3,1304482430503,14 TXN=null
This ends up triggering the null pointer exception b/c the TXN (which is of
type MultiTxn) is NULL due to a failed multi-op. I'll try to track down better
what the error handling is around a multi txn that fails and see why the Txn in
the snapshot is null...
> Need a multi-update command to allow multiple znodes to be updated safely
> -------------------------------------------------------------------------
>
> Key: ZOOKEEPER-965
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-965
> Project: ZooKeeper
> Issue Type: Bug
> Affects Versions: 3.3.3
> Reporter: Ted Dunning
> Assignee: Ted Dunning
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-965.patch, ZOOKEEPER-965.patch,
> ZOOKEEPER-965.patch, ZOOKEEPER-965.patch
>
>
> The basic idea is to have a single method called "multi" that will accept a
> list of create, delete, update or check objects each of which has a desired
> version or file state in the case of create. If all of the version and
> existence constraints can be satisfied, then all updates will be done
> atomically.
> Two API styles have been suggested. One has a list as above and the other
> style has a "Transaction" that allows builder-like methods to build a set of
> updates and a commit method to finalize the transaction. This can trivially
> be reduced to the first kind of API so the list based API style should be
> considered the primitive and the builder style should be implemented as
> syntactic sugar.
> The total size of all the data in all updates and creates in a single
> transaction should be limited to 1MB.
> Implementation-wise this capability can be done using standard ZK internals.
> The changes include:
> - update to ZK clients to all the new call
> - additional wire level request
> - on the server, in the code that converts transactions to idempotent form,
> the code should be slightly extended to convert a list of operations to
> idempotent form.
> - on the client, a down-rev server that rejects the multi-update should be
> detected gracefully and an informative exception should be thrown.
> To facilitate shared development, I have established a github repository at
> https://github.com/tdunning/zookeeper and am happy to extend committer
> status to anyone who agrees to donate their code back to Apache. The final
> patch will be attached to this bug as normal.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
