Skip to content
This repository has been archived by the owner on Apr 15, 2022. It is now read-only.

Refactor to use concurrent.futures #12

Merged
merged 44 commits into from
Jun 26, 2017
Merged

Refactor to use concurrent.futures #12

merged 44 commits into from
Jun 26, 2017

Conversation

aronasorman
Copy link
Collaborator

@aronasorman aronasorman commented May 24, 2017

Fixes #5 and #11. Changes:

  • refactor worker module from spawning our own worker threads, to using concurrent.futures.
  • simplify the worker implementation by removing the jobqueue and reportqueue. jobqueue is now handled by concurrent.futures, and then we just send any job updates straight to the messaging backend, removing the need for the reportqueue.
  • fix tests. Now only 1 test is failing all tests are passing on python 3.6!

Added:

  • Now implements progress tracking too.
  • Implements error reporting too.

So the general API found in InMemClient found here should be ready to use in Kolibri.

Added (05/26/2017):

  • simplified Scheduler implementation
  • added docstrings for Client (the main API) and Job
  • Add changelog !1875cab

@aronasorman aronasorman requested a review from benjaoming May 24, 2017 20:06
@aronasorman
Copy link
Collaborator Author

@benjaoming you'll be happy to know that I added a changelog based on http://keepachangelog.com/en/0.3.0/ :)

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](http://keepachangelog.com/)
and this project adheres to [Semantic Versioning](http://semver.org/).

This comment was marked as spam.

and this project adheres to [Semantic Versioning](http://semver.org/).


## [Unreleased]

This comment was marked as spam.

setup.py Outdated

def read_file(fname):
"""
Read file and decode in py2k
"""
if sys.version_info < (3,):
if IS_PYTHON_2:

This comment was marked as spam.


Jobs are stored on the storage backend for persistence through restarts, and are scheduled for running
to the workers.
"""
class State(enum.Enum):

This comment was marked as spam.

def shutdown(self):
# stub method, override if you need a more complex shut down procedure.
pass
return float(self.progress) / self.total_progress

This comment was marked as spam.

self.scheduler_thread.setDaemon(True)
def start_scheduler(self):
self.scheduler_thread = InfiniteLoopThread(func=self.schedule_next_job, thread_name="SCHEDULER",
wait_between_runs=0.5)

This comment was marked as spam.

This comment was marked as spam.

def start_worker_message_handler(self):
self.worker_message_handler_thread = InfiniteLoopThread(func=lambda: self.handle_worker_messages(timeout=2),
thread_name="WORKERMESSAGEHANDLER",
wait_between_runs=0.5)

This comment was marked as spam.

from collections import defaultdict
from threading import Event

JOB_EVENT_MAPPING = defaultdict(lambda: Event())

This comment was marked as spam.

This comment was marked as spam.

except queue.Empty:
# Maybe it's been processed already... just continue anyway then.
inmem_client._storage.wait_for_job_update(job_id, timeout=2)
except Exception:

This comment was marked as spam.

This comment was marked as spam.

@@ -28,7 +29,7 @@ def test_can_schedule_single_job(self, defaultbackend, simplejob):
new_job = defaultbackend.get_job(job_id)

# Does the returned job record the function we set to run?
assert str(new_job.func) == str(id)
assert str(new_job.func) == stringify_func(id)

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

@benjaoming
Copy link
Contributor

benjaoming commented May 30, 2017

If you rebase/merge develop, we should have more accurate test failures regarding Python 2.7 and pypy.

@aronasorman
Copy link
Collaborator Author

Thanks! Looking over your changes now. Some quick notes:

The usage of the compat.py file seems to be a bit weird for me. I'd rather import six and use the compatibility modules there, as I'm imagining that we'll need more of those in the future.

I generally don't put logging statements in my testing code, as the default logging.debug statements i sprinkled in already provide enough data to help debug (apart from running just one test that's failing). What do you think?

@benjaoming
Copy link
Contributor

The usage of the compat.py file seems to be a bit weird for me. I'd rather import six and use the compatibility modules there, as I'm imagining that we'll need more of those in the future.

If six does it, we should use six. For things that aren't supplied in six, it's very important to gather the compatibility hacks in one place. Otherwise they linger around forever. Been removing plenty of stale 2.5 and 2.6 compatibility hacks :)

@benjaoming
Copy link
Contributor

I generally don't put logging statements in my testing code, as the default logging.debug statements i sprinkled in already provide enough data to help debug (apart from running just one test that's failing). What do you think?

We can do lots of logging because pytest is clever enough to not display any of the logging done by successful tests.. Anyways, having lots of logging will also make test code less readable. So probably not so nice to leave it around. Was looking at test code in Django, and they don't log anything.

I don't remember where my original comment about it was, but it had to do with a test that froze and I couldn't even know what test it was executing and get the logging output. So in this case I could troubleshoot it by logging and using pytest -s so it would forward the logging directly to stderr.

Jobs aren't being viewed still :(
@benjaoming
Copy link
Contributor

Test builds are complaining about not finding a barbequeue distribution, did you start the name change?

@benjaoming
Copy link
Contributor

@aronasorman let me know anytime you want a mid-term review :)

@benjaoming
Copy link
Contributor

Hi @aronasorman !

So the commit 391bb9f in this unmerged PR is the one that Kolibri is currently running on? :)

There are two quick comments remaining from my previous review, that I think you can fix up quickly?

I'm optimistic we should get this merged and try to get on track with smaller issues, PRs, and versioning+releasing of Iceqube (yeah the name refactor is probably best to have cleared, too).. it seems easier than sitting on this rather lengthy PR and starting to release Kolibri with some commit ID ref'ed in a dependency link.

Apparently on Android, even just importing processpoolexecutor would cause an error.
@aronasorman
Copy link
Collaborator Author

Think I addressed the important comments, merging this in now!

@aronasorman aronasorman merged commit 95212eb into develop Jun 26, 2017
pytest-mock==1.6.0
pytest-cov

This comment was marked as spam.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants