PyrakoonClient can use multiple clients to improve throughput in threaded situations (like the DAL)#215
Conversation
…aded situations (like the DAL)
ghost
assigned
| Package: openvstorage-extensions | ||
| Architecture: amd64 | ||
| Pre-Depends: python (>= 2.7.2), python-paramiko, python-rpyc, python-protobuf, python-requests (>=2.9.1), python-ujson | ||
| Pre-Depends: python (>= 2.7.2), python-gevent (>= 0.13.0-1build2), python-paramiko, python-rpyc, python-protobuf, |
| """ | ||
| raise NotImplementedError() | ||
|
|
||
| def set(self, key, value, transaction=None): |
There was a problem hiding this comment.
as stated in earlier discussions, I'm not a fan of the transaction = None) parameter, especially given that the parameter added here is a string. You might as well have the sequence as a parameter, or use the comfort calls on the sequence and remove this parameter altogether. With a sequence, it's absolutely clear no communication with the server is happening at all, and what the allowed set of scenarios is. Now it's less so.
There was a problem hiding this comment.
Out of scope for the current changes really. It will require some refactor work
| :return: The next key | ||
| :rtype: str | ||
| """ | ||
| encoding = 'ascii' # For future python 3 compatibility |
| array = array[:-1] | ||
| return str(array.decode(encoding)) | ||
| array[index] = 0 | ||
| return '\xff' |
| """ | ||
| Apply a transaction which is the result of the callback. | ||
| The callback should build the complete transaction again to handle the asserts. If the possible previous run was interrupted, | ||
| the Arakoon might only have partially applied all actions therefore all asserts must be re-evaluated |
There was a problem hiding this comment.
As in get interrupted mid sequence because of an assert and not do anything at all.
It's bad phrasing
|
|
||
| _logger = Logger('extensions') | ||
|
|
||
| # Frequency at which the pool is populated at startup |
| Add a new client to the pool | ||
| :return: None | ||
| """ | ||
| sleep_time = 0.1 |
There was a problem hiding this comment.
what does this have to do with the SPAWN_FREQUENCY ?
There was a problem hiding this comment.
Its just a retry-interval
| tries += 1 | ||
| try: | ||
| transaction = transaction_callback() # type: str | ||
| return self.apply_transaction(transaction) |
There was a problem hiding this comment.
why have a succes variable if you never set it to True ?
2 participants
No description provided.