Skip to content
Newer
Older
100644 333 lines (185 sloc) 16.8 KB
6623eb7 @slyphon bump for 1.9.0 release
slyphon authored
1 This file notes feature differences and bugfixes contained between releases.
2
5854b33 @slyphon prep for 1.9.6 release
slyphon authored
3 ### v1.9.6 ###
4
5 * Fixes from @rickypai for ruby 2.2 (#89)
6 * Remove dependency on logging gem #90 (h/t: @eric)
7
97d277c @slyphon prep for v1.9.5
slyphon authored
8 ### v1.9.5 ###
9
10 * Really clear hooks when clear! is called #83 (h/t: Liam Stewart)
11 * implement `add_auth` method to send credentials to zookeeper #86 (h/t: ajf8)
12
34cbb75 @slyphon upgrade logging gem, remove simplecov
slyphon authored
13 ### v1.9.4 ###
14
15 * Forward options to underlying connection #69 (h/t: avalanche123)
16 * Don't check connection state in Locker#assert! - leads to better retry behavior
17 * allow specifying session-id
18 * upgrade logging gem dependency
19
20
c90de97 @eric Get ready for the release of 1.9.3
eric authored
21 ### v1.9.3 ###
22
23 * Fix deadlocks between watchers and reconnecting
24
25
d7340ad @eric Add release notes
eric authored
26 ### v1.9.2 ###
27
28 * Fix re-watching znodes after a lost session #72 (reported by kalantar)
29
30
6da836c @eric Remove unreleased identifier
eric authored
31 ### v1.9.1 ###
f1e7afd @eric Update RELEASES
eric authored
32
d7340ad @eric Add release notes
eric authored
33 * Fix re-rewatching children watchers after the parent znode was deleted #68
d7760d6 @eric Add more to RELEASES
eric authored
34 * Deal with reopening a closed connection properly #70
f1e7afd @eric Update RELEASES
eric authored
35
36
6623eb7 @slyphon bump for 1.9.0 release
slyphon authored
37 ### v1.9.0 ###
38
39 * Semaphores!
40 * shared/exclusive lock fixes
6a02d84 @slyphon doc tweaks
slyphon authored
41
91f2795 @slyphon prep for 1.8.0 release
slyphon authored
42 ### v1.8.0 ###
43
44 * Added non-exploderating Locker#assert method (issue #48, h/t: johnbellone)
45
4262a07 @slyphon bump version to 1.7.5
slyphon authored
46 ### v1.7.5 ###
47
48 * fix for jruby 1.7 (issue #53)
49
0a55abd @slyphon fix a nasty issue on connection loss (but not session expiration) wit…
slyphon authored
50 ### v1.7.4 ###
51
c90de97 @eric Get ready for the release of 1.9.3
eric authored
52 * Narsty bug in Locker (#54)
0a55abd @slyphon fix a nasty issue on connection loss (but not session expiration) wit…
slyphon authored
53
54 If a locker is waiting on the lock, and a connection interruption occurs (that doesn't render the session invalid), the waiter will attempt to clean up while the connection is invalid, and not succeed in cleaning up its ephemeral. This patch will recognize that the `@lock_path` was already acquired, and just wait on the current owner (ie. it won't create an erroneous *third* lock node). The reproduction code has been added under `spec/informal/two-locks-enter-three-locks-leave.rb`
55
56
a593340 @slyphon bump version to 1.7.3
slyphon authored
57 ### v1.7.3 ###
58
59 * bug fix for "Callbacks Hash in EventHandlerSubscription::Base gets longer randomly" (#52)
60
61 I'd like to point out that the callbacks hash gets longer *deterministically*, depending on what callbacks get registered. This patch will do further cleanup so as not to leave empty arrays littering the EventHandler.
62
63 ### v1.7.2 ###
64
65 * bug fix for "Ephemeral node for exclusive lock not cleaned up when failure happens during lock acquisition" (#51)
66
518bd87 @slyphon closes #49, prep for release of 1.7.1
slyphon authored
67 ### v1.7.1 ###
68
69 * Fixes nasty bug "LockWaitTimeout causes lock to be forever unusable" (#49)
70
71 The code path in the case of a LockWaitTimeout would skip the lock node cleanup, so a given lock name would become unusable until the timed-out-locker's session went away. This fixes that case and adds specs.
72
dd1a5af @slyphon add RELEASES and README notes about 1.7.0 :wait feature
slyphon authored
73 ### v1.7.0 ###
74
75 * Added Locker timeout feature for blocking calls. (issue #40)
76
c90de97 @eric Get ready for the release of 1.9.3
eric authored
77 Previously, when dealing with locks, there were only two options: blocking or non-blocking. In order to come up with a time-limited lock, you had to poll every so often until you acquired the lock. This is, needless to say, both inefficient and doesn't allow for fair acquisition.
dd1a5af @slyphon add RELEASES and README notes about 1.7.0 :wait feature
slyphon authored
78
c90de97 @eric Get ready for the release of 1.9.3
eric authored
79 A timeout option has been added so that when blocking waiting for a lock, you can specify a deadline by which the lock should have been acquired.
dd1a5af @slyphon add RELEASES and README notes about 1.7.0 :wait feature
slyphon authored
80
81 ```ruby
82 zk = ZK.new
83
84 locker = zk.locker('lock name')
85
86 begin
87 locker.lock(:wait => 5.0) # wait up to 5.0 seconds to acquire the lock
88 rescue ZK::Exceptions::LockWaitTimeoutError
89 $stderr.puts "could not acquire the lock in time"
90 end
91 ```
92
93 Also available when using the convenience `#with_lock` methods
94
95 ```ruby
96
97 zk = ZK.new
98
99 begin
100 zk.with_lock('lock name', :wait => 5.0) do |lock|
101 # do stuff while holding lock
102 end
103 rescue ZK::Exceptions::LockWaitTimeoutError
104 $stderr.puts "could not acquire the lock in time"
105 end
106
107 ```
108
109
c8ad122 @slyphon bump version, add release notes
slyphon authored
110 ### v1.6.4 ###
111
112 * Remove unnecessary dependency on backports gem
113 * Fix for use in resque! A small bug was preventing resque from activating the fork hook.
114
17508dc @slyphon add 1.6.3 note
slyphon authored
115 ### v1.6.3 ###
116
117 * Retry when lock creation fails due to a NoNode exception
118
95ce4f8 @slyphon 1.6.2 RELEASES message, tweak README
slyphon authored
119 ### v1.6.2 ###
120
121 * Change state call to reduce the chances of deadlocks
122
123 One of the problems I've been seeing is that during some kind of shutdown event, some method will call `closed?` or `connected?` which will acquire a mutex and make a call on the underlying connection at the *exact* moment necessary to cause a deadlock. In order to help prevent this, and building on some changes from 1.5.3, we now treat our cached `@last_cnx_state` as the current state of the connection and don't touch the underlying connection object (except in the case of the java driver, which is safe).
124
3cf3c65 @slyphon releases note for 1.6.1
slyphon authored
125 ### v1.6.1 ###
126
127 * Small fixes for zk-eventmachine compatibilty
128
84a1ac0 @slyphon Add ZK::Locker.cleanup (closes #33)
slyphon authored
129 ### v1.6.0 ###
130
131 * Locker cleanup code!
132
133 When a session is lost, it's likely that the locker's node name was left behind. so for `zk.locker('foo')` if the session is interrupted, it's very likely that the `/_zklocking/foo` znode has been left behind. A method has been added to allow you to safely clean up these stale znodes:
134
135 ```ruby
136 ZK.open('localhost:2181') do |zk|
137 ZK::Locker.cleanup(zk)
138 end
139 ```
140
141 Will go through your locker nodes one by one and try to lock and unlock them. If it succeeds, the lock is naturally cleaned up (as part of the normal teardown code), if it doesn't acquire the lock, then no harm, it knows that lock is still in use.
142
89d83ab @slyphon add a note about create :or => :set
slyphon authored
143 * Added `create('/path', 'data', :or => :set)` which will create a node (and all parent paths) with the given data or set its contents if it already exists. It's intended as a convenience when you just want a node to exist with a particular value.
144
84a1ac0 @slyphon Add ZK::Locker.cleanup (closes #33)
slyphon authored
145 ### v1.5.3 ###
146
c90de97 @eric Get ready for the release of 1.9.3
eric authored
147 * Fixed reconnect code. There was an occasional race/deadlock condition caused because the reopen call was done on the underlying connection's dispatch thread. Closing the dispatch thread is part of reopen, so this would cause a deadlock in real-world use. Moved the reconnect logic to a separate, single-purpose thread on ZK::Client::Threaded that watches for connection state changes.
84a1ac0 @slyphon Add ZK::Locker.cleanup (closes #33)
slyphon authored
148
149 * 'private' is not 'protected'. I've been writing ruby for several years now, and apparently I'd forgotten that 'protected' does not work like how it does in java. The visibility of these methods has been corrected, and all specs pass, so I don't expect issues...but please report if this change causes any bugs in user code.
150
151
814e025 @slyphon update RELEASES file
slyphon authored
152 ### v1.5.2 ###
153
154 * Fix locker cleanup code to avoid a nasty race when a session is lost, see [issue #34](https://github.com/slyphon/zk/issues/34)
155
156 * Fix potential deadlock in ForkHook code so the mutex is unlocked in the case of an exception
157
158 * Do not hang forever when shutting down and the shutdown thread does not exit (wait 30 seconds).
159
66d69a6 @slyphon add 1.5.1 release info and document :retry_duration
slyphon authored
160 ### v1.5.1 ###
161
c90de97 @eric Get ready for the release of 1.9.3
eric authored
162 * Added a `:retry_duration` option to client constructor which will allows the user to specify for how long in the case of a connection loss, should an operation wait for the connection to be re-established before retrying the operation. This can be set at a global level and overridden on a per-call basis. The default is to not retry (which may change at a later date). Generally speaking, a timeout of > 30s is probably excessive, and care should be taken because during a connection loss, the server-side state may change without you being aware of it (i.e. events will not be delivered).
66d69a6 @slyphon add 1.5.1 release info and document :retry_duration
slyphon authored
163
164 * Small fork-hook implementation fix. Previously we were using WeakRefs so that hooks would not prevent an object from being garbage collected. This has been replaced with a finalizer which is more deterministic.
165
5a320f6 @slyphon add README and RELEASES entries for 1.5.0
slyphon authored
166 ### v1.5.0 ###
167
c90de97 @eric Get ready for the release of 1.9.3
eric authored
168 Ok, now seriously this time. I think all of the forking issues are done.
5a320f6 @slyphon add README and RELEASES entries for 1.5.0
slyphon authored
169
c90de97 @eric Get ready for the release of 1.9.3
eric authored
170 * Implemented a 'stop the world' feature to ensure safety when forking. All threads are stopped, but state is preserved. `fork()` can then be called safely, and after fork returns, all threads will be restarted in the parent, and the connection will be torn down and reopened in the child.
5a320f6 @slyphon add README and RELEASES entries for 1.5.0
slyphon authored
171
12cd798 @slyphon tweak RELEASES file
slyphon authored
172 * The easiest, and supported, way of doing this is now to call `ZK.install_fork_hook` after requiring zk. This will install an `alias_method_chain` style hook around the `Kernel.fork` method, which handles pausing all clients in the parent, calling fork, then resuming in the parent and reconnecting in the child. If you're using ZK in resque, I *highly* recommend using this approach, as it will give the most consistent results.
5a320f6 @slyphon add README and RELEASES entries for 1.5.0
slyphon authored
173
174 * Logging is now off by default, and uses the excellent, can't-recommend-it-enough, [logging](https://github.com/TwP/logging) gem. If you want to tap into the ZK logs, you can assign a stdlib compliant logger to `ZK.logger` and that will be used. Otherwise, you can use the Logging framework's controls. All ZK logs are consolidated under the 'ZK' logger instance.
175
aa23e30 @slyphon prepare for 1.4.1 release
slyphon authored
176 ### v1.4.1 ###
177
178 * True fork safety! The `zookeeper` at 1.1.0 is finally fork-safe. You can now use ZK in whatever forking library you want. Just remember to call `#reopen` on your client instance in the child process before attempting any opersations.
179
180
6c9f56d @slyphon document children, and update RELEASES
slyphon authored
181 ### v1.4.0 ###
182
e2e0b2b @slyphon readme and releases update for 1.4.0
slyphon authored
183 * Added a new `:ignore` option for convenience when you don't care if an operation fails. In the case of a failure, the method will return nil instead of raising an exception. This option works for `children`, `create`, `delete`, `get`, `get_acl`, `set`, and `set_acl`. `stat` will ignore the option (because it doesn't care about the state of a node).
6c9f56d @slyphon document children, and update RELEASES
slyphon authored
184
185 ```
186 # so instead of having to do:
187
188 begin
189 zk.delete('/some/path')
190 rescue ZK::Exceptions;:NoNode
191 end
192
193 # you can do
194
195 zk.delete('/some/path', :ignore => :no_node)
196
197 ```
198
e2e0b2b @slyphon readme and releases update for 1.4.0
slyphon authored
199 * MASSIVE fork/parent/child test around event delivery and much greater stability expected for linux (with the zookeeper-1.0.3 gem). Again, please see the documentation on the wiki about [proper fork procedure](http://github.com/slyphon/zk/wiki/Forking).
6c9f56d @slyphon document children, and update RELEASES
slyphon authored
200
46fd5f4 @slyphon update RELEASES doc
slyphon authored
201 ### v1.3.1 ###
202
203 * [fix a bug][bug 1.3.1] where a forked client would not have its 'outstanding watches' cleared, so some events would never be delivered
204
205 [bug 1.3.1]: https://github.com/slyphon/zk/compare/release/1.3.0...9f68cee958fdaad8d32b6d042bf0a2c9ab5ec9b0
206
207 ### v1.3.0 ###
208
209 Phusion Passenger and Unicorn users are encouraged to upgrade!
210
211 * __fork()__: ZK should now work reliably after a fork() if you call `reopen()` ASAP in the child process (before continuing any ZK work). Additionally, your event-handler (blocks set up with `zk.register`) will still work in the child. You will have to make calls like `zk.stat(path, :watch => true)` to tell ZooKeeper to notify you of events (as the child will have a new session), but everything should work.
212
213 * See the fork-handling documentation [on the wiki](http://github.com/slyphon/zk/wiki/Forking).
214
215
9bb0f3d @slyphon update README and RELEASES for 1.2 release
slyphon authored
216 ### v1.2.0 ###
217
218 You are __STRONGLY ENCOURAGED__ to go and look at the [CHANGELOG](http://git.io/tPbNBw) from the zookeeper 1.0.0 release
219
c90de97 @eric Get ready for the release of 1.9.3
eric authored
220 * NOTICE: This release uses the 1.0 release of the zookeeper gem, which has had a MAJOR REFACTORING of its namespaces. Included in that zookeeper release is a compatibility layer that should ease the transition, but any references to Zookeeper\* heirarchy should be changed.
9bb0f3d @slyphon update README and RELEASES for 1.2 release
slyphon authored
221
222 * Refactoring related to the zokeeper gem, use all the new names internally now.
223
224 * Create a new Subscription class that will be used as the basis for all subscription-type things.
225
226 * Add new Locker features!
227 * `LockerBase#assert!` - will raise an exception if the lock is not held. This check is not only for local in-memory "are we locked?" state, but will check the connection state and re-run the algorithmic tests that determine if a given Locker implementation actually has the lock.
c90de97 @eric Get ready for the release of 1.9.3
eric authored
228 * `LockerBase#acquirable?` - an advisory method that checks if any condition would prevent the receiver from acquiring the lock.
9bb0f3d @slyphon update README and RELEASES for 1.2 release
slyphon authored
229
230 * Deprecation of the `lock!` and `unlock!` methods. These may change to be exception-raising in a future relase, so document and refactor that `lock` and `unlock` are the way to go.
231
232 * Fixed a race condition in `event_catcher_spec.rb` that would cause 100% cpu usage and hang.
233
b5fb462 @slyphon prep for 1.1.1
slyphon authored
234 ### v1.1.1 ###
235
236 * Documentation for Locker and ilk
237
238 * Documentation cleanup
239
240 * Fixes for Locker tests so that we can run specs against all supported ruby implementations on travis (relies on in-process zookeeper server in the zk-server-1.0.1 gem)
241
c90de97 @eric Get ready for the release of 1.9.3
eric authored
242 * Support for 1.8.7 will be continued
b5fb462 @slyphon prep for 1.1.1
slyphon authored
243
244 ## v1.1.0 ##
245
246 (forgot to put this here, put it in the readme though)
247
248 * NEW! Thread-per-Callback event delivery model! [Read all about it!](https://github.com/slyphon/zk/wiki/EventDeliveryModel). Provides a simple, sane way to increase the concurrency in your ZK-based app while maintaining the ordering guarantees ZooKeeper makes. Each callback can perform whatever work it needs to without blocking other callbacks from receiving events. Inspired by [Celluloid's](https://github.com/celluloid/celluloid) actor model.
249
250 * Use the [zk-server](https://github.com/slyphon/zk-server) gem to run a standalone ZooKeeper server for tests (`rake SPAWN_ZOOKEEPER=1`). Makes live-fire testing of any project that uses ZK easy to run anywhere!
251
d0c18a7 @slyphon adding a RELEASES file to track user-facing feature changes.
slyphon authored
252
31148ea @slyphon update releases file
slyphon authored
253 ### v1.0.0 ###
254
8a25c3e @slyphon making sure this yak is shaved clean. more RELEASES tweaking
slyphon authored
255 * Threaded client (the default one) will now automatically reconnect (i.e. `reopen()`) if a `SESSION_EXPIRED` or `AUTH_FAILED` event is received. Thanks to @eric for pointing out the _nose-on-your-face obviousness_ and importance of this. If users want to handle these events themselves, and not automatically reopen, you can pass `:reconnect => false` to the constructor.
256
faba133 @slyphon update RELEASES
slyphon authored
257 * allow for both :sequence and :sequential arguments to create, because I always forget which one is the "right one"
31148ea @slyphon update releases file
slyphon authored
258
faba133 @slyphon update RELEASES
slyphon authored
259 * add zk.register(:all) to recevie node updates for all nodes (i.e. not filtered on path)
260
c90de97 @eric Get ready for the release of 1.9.3
eric authored
261 * add 'interest' feature to zk.register, now you can indicate what kind of events should be delivered to the given block (previously you had to do that filtering inside the block). The default behavior is still the same, if no 'interest' is given, then all event types for the given path will be delivered to that block.
d1107ab @slyphon make a note of the feature in the RELEASES file
slyphon authored
262
263 zk.register('/path', :created) do |event|
264 # event.node_created? will always be true
265 end
266
267 # or multiple kinds of events
268
269 zk.register('/path', [:created, :changed]) do |event|
270 # (event.node_created? or event.node_changed?) will always be true
271 end
272
faba133 @slyphon update RELEASES
slyphon authored
273 * create now allows you to pass a path and options, instead of requiring the blank string
274
275 zk.create('/path', '', :sequential => true)
276
277 # now also
278
279 zk.create('/path', :sequential => true)
31148ea @slyphon update releases file
slyphon authored
280
11030c3 @slyphon update RELEASES file
slyphon authored
281 * fix for shutdown: close! called from threadpool will do the right thing
282
c90de97 @eric Get ready for the release of 1.9.3
eric authored
283 * Chroot users rejoice! By default, ZK.new will create a chrooted path for you.
284
0f287bb @slyphon add chroot feature to RELEASES file
slyphon authored
285 ZK.new('localhost:2181/path', :chroot => :create) # the default, create the path before returning connection
286
287 ZK.new('localhost:2181/path', :chroot => :check) # make sure the chroot exists, raise if not
288
91afafe @slyphon change chroot option from the ambiguous :ignore to :do_nothing
slyphon authored
289 ZK.new('localhost:2181/path', :chroot => :do_nothing) # old default behavior
0f287bb @slyphon add chroot feature to RELEASES file
slyphon authored
290
291 # and, just for kicks
c90de97 @eric Get ready for the release of 1.9.3
eric authored
292
0f287bb @slyphon add chroot feature to RELEASES file
slyphon authored
293 ZK.new('localhost:2181', :chroot => '/path') # equivalent to 'localhost:2181/path', :chroot => :create
294
3bbd3fd @slyphon note event module in RELEASES
slyphon authored
295 * Most of the event functionality used is now in a ZK::Event module. This is still mixed into the underlying slyphon-zookeeper class, but now all of the important and relevant methods are documented, and Event appears as a first-class citizen.
d1107ab @slyphon make a note of the feature in the RELEASES file
slyphon authored
296
f9e4d4b @slyphon Make the 1.0 changes more visible in the README.
slyphon authored
297 * Support for 1.8.7 WILL BE *DROPPED* in v1.1. You've been warned.
298
68776ef @slyphon (belatedly) update with 0.9.1 info
slyphon authored
299 ### v0.9.1 ###
300
301 The "Don't forget to update the RELEASES file before pushing a new release" release
302
303 * Fix a fairly bad bug in event de-duplication (diff: http://is.gd/a1iKNc)
c90de97 @eric Get ready for the release of 1.9.3
eric authored
304
68776ef @slyphon (belatedly) update with 0.9.1 info
slyphon authored
305 This is fairly edge-case-y but could bite someone. If you'd set a watch
306 when doing a get that failed because the node didn't exist, any subsequent
307 attempts to set a watch would fail silently, because the client thought that the
308 watch had already been set.
c90de97 @eric Get ready for the release of 1.9.3
eric authored
309
68776ef @slyphon (belatedly) update with 0.9.1 info
slyphon authored
310 We now wrap the operation in the setup_watcher! method, which rolls back the
311 record-keeping of what watches have already been set for what nodes if an
312 exception is raised.
c90de97 @eric Get ready for the release of 1.9.3
eric authored
313
68776ef @slyphon (belatedly) update with 0.9.1 info
slyphon authored
314 This change has the side-effect that certain operations (get,stat,exists?,children)
315 will block event delivery until completion, because they need to have a consistent
316 idea about what events are pending, and which have been delivered. This also means
317 that calling these methods represent a synchronization point between user threads
318 (these operations can only occur serially, not simultaneously).
319
320
d0c18a7 @slyphon adding a RELEASES file to track user-facing feature changes.
slyphon authored
321 ### v0.9.0 ###
322
323 * Default threadpool size has been changed from 5 to 1. This should only affect people who are using the Election code.
324 * `ZK::Client::Base#register` delegates to its `event_handler` for convenience (so you can write `zk.register` instead of `zk.event_handler.register`, which always irked me)
325 * `ZK::Client::Base#event_dispatch_thread?` added to more easily allow users to tell if they're currently in the event thread (and possibly make decisions about the safety of their actions). This is now used by `block_until_node_deleted` in the Unixisms module, and prevents a situation where the user could deadlock event delivery.
326 * Fixed issue 9, where using a Locker in the main thread would never awaken if the connection was dropped or interrupted. Now a `ZK::Exceptions::InterruptedSession` exception (or mixee) will be thrown to alert the caller that something bad happened.
327 * `ZK::Find.find` now returns the results in sorted order.
328 * Added documentation explaining the Pool class, reasons for using it, reasons why you shouldn't (added complexities around watchers and events).
c90de97 @eric Get ready for the release of 1.9.3
eric authored
329 * Began work on an experimental Multiplexed client, that would allow multithreaded clients to more effectively share a single connection by making all requests asynchronous behind the scenes, and using a queue to provide a synchronous (blocking) API.
d0c18a7 @slyphon adding a RELEASES file to track user-facing feature changes.
slyphon authored
330
331
31148ea @slyphon update releases file
slyphon authored
332 # vim:ft=markdown:sts=2:sw=2:et
Something went wrong with that request. Please try again.