IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
- when we do a store_unlock the lock record becomes unlocked, so we
must destroy it (or we leak memory)
(This used to be ctdb commit d85955640e670dd580073da96b25fb8a10c08d18)
they both successfully fetch and lock the same record at this stage but when the actual locking works properly the second child will block.
this test allows us to verify the blocking once we have implemented it
(This used to be ctdb commit b1c0baa03a669757aaacb6e1a2794224f5ba2cd7)
there is still a bug in the ctdb code in that the children no longer receive messages from the parent for unknown reasons
(This used to be ctdb commit 468f68e4607900c5c38aea428a48dd6ea1647411)
this makes it possible to do fetch_lock and store_unlock across a domain socket to read/write data.
note that the actual locking is NOT implemented yet
(This used to be ctdb commit c7a397c56caf71283c081e5b97620085ed5108c6)
for now:
fetch a record
store a known entry for this record
fetch the record again (and later verify we got the same record)
store it back again
this will not work right now since we dont yet store the record inside the daemon
(This used to be ctdb commit f502094499a3c25ab58aa3d192588b5e6dd2b8e4)
note that the store_unlock does not actually do anything yet apart from passing the pdu from client to daemon and daemon responds.
next is to make sure the daemon actually stores the data in a database
(This used to be ctdb commit 167d6993e78f6a1d0f6607ef66925a14993ae6a1)
right now this test only does one fetch lock but this will be enhanced as more code is added to ctdb to handle fetch_lock and store_unlock
(This used to be ctdb commit 996f117d9181dee22aea979ce04333035f5522c7)
we cant peek in state->c since this is uninitialized
and even if it were not it would be wrong
create a new structure to pass BOTH client and also the reqid to respond back to
the client with
(This used to be ctdb commit e1a0da3dfbb4a927e8d98723b5e51a201c2a3428)
no locking is yet done and the store_unlock call is still missing
the ./tests/fetch.sh --daemon test fails with parent process dying which needs to be investigated.
(This used to be ctdb commit 7d7141c968950a8856f1be79871932b688bfb07f)
read returns 0 bytes this means the client has exited. Close the connection
then.
(This used to be ctdb commit bd10f4e62146493848258df8a3dc3b9222337a12)
(send a message to ourself)
this unfortunately terminates the ctdb daemon when running but im too tired right now to debug it.
checkin so that nothing gets lost overnight.
(This used to be ctdb commit 9d8821bfd1456591fb5c31f0c6c3fd63e99dc4fb)
create a small test application that connects to the ctdb daemon at /tmp/ctdb.socket.127.0.0.1 and do some commands to the daemon.
currently this test tool only opens the socket and registers its pid with the daemon
(the daemon needs to know the pid so that it can forward messages to the correct client)
the test will be extended with additional ctdb commands
(This used to be ctdb commit 801f6127cdd50c5b2d0e64dd8db08500af9dadc9)
- split client specific routines out of ctdb_daemon.c
- use ctdb_queue code in message send from client to daemon
- use clearer names in client/daemon functions
- use talloc autofree context to avoid global for unlink of socket on
exit
- start on API change for message handler, to allow ctdb messaging to
handle daemon mode with multiple clients
(This used to be ctdb commit 53555db45f3583ae4a32cc3aa9e07fb8ef2a77e3)
