adds new_session_client method #100

marrony · 2016-10-24T20:45:08Z

closes https://github.com/faunadb/sales-engineering/issues/353

erickpintor · 2016-10-25T13:44:39Z

faunadb/client.py

+    if observer is None:
+      observer = self.observer
+
+    return Client(self.domain, self.scheme, self.port, self.session.timeout, secret, observer)


Are you sharing the underlying http connection pool if you don't share session object?

No, and I don't think it's possible, because session object hold the headers with the authentication. I might be wrong though but I don't find good examples except ones that says it's thread safe but it's a different thing

ashfire908 · 2016-10-25T21:38:57Z

faunadb/client.py

@@ -91,6 +91,12 @@ def ping(self, scope=None, timeout=None):
    """
    return self._execute("GET", "ping", query={"scope": scope, "timeout": timeout})

+  def new_session_client(self, secret, observer=None):


IMO, this is kind of a clunky title, and it's also not documented what this does or is for, so from both of these points, the user of this library will probably find this method a mystery.

If anyone oppose, I'll use ruby driver as a reference to this

Fine by me, though I'm biased 😛

Just to confirm, with_secret still a good name for this method?

I think so, yes.

marrony · 2016-10-26T00:04:39Z

faunadb/client.py

+    if observer is None:
+      observer = self.observer
+
+    return Client(self.domain, self.scheme, self.port, self.session.timeout, secret, observer)


Need to rename this when #99 get closed

I think my previous question still applies here:

Are you sharing the underlying http connection pool if you don't share session object?

Each session has it's own connection pool.

What about the thread pool? Is it the same for all http calls or each session object has its own?

From what I gather in the source code, it doesn't seem to have a thread pool. As far as I can tell, it just performs the request on the thread that made the request.

What are we trying to determine here?

Sorry, I should have explained that before.

The whole reason why we came up with this session client concept is that we could share the underlying http resources (connection pool and thread pool) with short live clients.

Those clients are usually used when you have a instance specific token that is required to validate a specific query.

In Java, for instance, if you just advise people to create new clients for those scenarios, they could run out or threads or file descriptors as each new client would create new pools.

What I'm trying to understand is if we are wasting resources or causing problems under high load by not sharing the underneath Session object between clients.

If we want to share sessions between clients, we'll have to move the credentials to where we do each request, rather than setting it at the session level. We'll obviously also have to figure out where we want to put the shared session object.

Yeah. That is true. Unless we follow the Scala approach, if that makes sense for python of course.

I guess what we need to figure out first is if we are causing any potential harm by creating several session objects. We need to understand how it uses its connection and thread pools, if any.

Well, I was poking around and found some places that says it might not be a good idea to share the same Session object among multiple threads, at least for now.

There are some open discussions on GH
https://github.com/kennethreitz/requests/issues/1871
https://github.com/kennethreitz/requests/issues/2766

and some recommendations on SO
http://stackoverflow.com/questions/18188044/is-the-session-object-from-pythons-requests-library-thread-safe

this one was randomly found
http://toolbelt.readthedocs.io/en/latest/threading.html

A requests Session is documented as threadsafe but there are still a couple corner cases where it isn’t perfectly threadsafe. The best way to use a Session is to use one per thread.

This is odd.

I was looking at the code for requests library. It seems like Session object is thread safe as long as we don't mutate its attributes after it's constructed.

It also feels weird to use a session per thread, as suggest by stack overflow, since each session will have its own connection pool. For short live threads, such as a http request, tcp connections won't be reused at all.

The default connection pool size is 10 by default. Which seems a little low to me.

IMO, the ideal implementation would be:

Provide a configuration so the users can change the number of connections as they initialize FaunaClient. Perhaps allow a little more than 10 by default?

Move the authentication to the request rather than the session object.

Share the session object between connections, making sure it's not mutated anywhere, so it reuses underlying tcp connections to fauna.

erickpintor · 2016-10-26T11:01:54Z

faunadb/client.py

+    if observer is None:
+      observer = self.observer
+
+    return Client(self.domain, self.scheme, self.port, self.session.timeout, secret, observer)


I think my previous question still applies here:

Are you sharing the underlying http connection pool if you don't share session object?

erickpintor · 2016-10-26T11:04:40Z

faunadb/client.py

@@ -91,6 +91,21 @@ def ping(self, scope=None, timeout=None):
    """
    return self._execute("GET", "ping", query={"scope": scope, "timeout": timeout})

+  def with_secret(self, secret, observer=None):


IMO, when I read with_secret, I would expect the method to receive a lambda and perform the produced queries with a different secret.

That would avoid the need for a reference count in order to manage shared resources.

codecov-io · 2016-11-03T15:46:51Z

Current coverage is 99.79% (diff: 97.22%)

Merging #100 into master will increase coverage by 0.22%

@@             master       #100   diff @@
==========================================
  Files             9          9          
  Lines           462        489    +27   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
+ Hits            460        488    +28   
+ Misses            2          1     -1   
  Partials          0          0

Powered by Codecov. Last update 397d587...a6c77bc

erickpintor · 2016-11-03T16:04:38Z

faunadb/client.py

+      Callback that will be passed a :any:`RequestResult` after every completed request.
+    :return:
+    """
+    if self.counter.get() > 0:


You should use increment here. There is a chance that get returns more than zero but immediately after some other thread decrements and close the session you're sharing with the new client.

marrony · 2016-11-03T16:08:04Z

do we have a verdict here on what should be the name? new_session_client or with_secret?

FYI: my last commit made the clients share the same Session object with a ref counter. About add an option to increase/decrease the threadpool, the only way I see was to add a new adapter, pretty much like this example https://github.com/kennethreitz/requests/blob/master/docs/user/advanced.rst#example-specific-ssl-version

erickpintor · 2016-11-03T16:13:41Z

If you return a new client, I think new_session_client is a proper name. If you receive a lambda and just execute it on a contained method, with_secret seems better.

For the pool size, I think you can try to mount http and https to the same adapter but, with a different pool size.

erickpintor · 2016-11-03T18:00:04Z

faunadb/client.py

+  def __str__(self):
+    return "Counter(%s)" % self.counter
+
+  def increment(self):


Method not used anymore.

erickpintor · 2016-11-03T18:05:12Z

faunadb/client.py

+      self.counter += 1
+      return self.counter
+
+  def get_and_increment(self):


There is still a race condition in here:

Thread 1 calls decrement: decrements counter to 0 and close the session

Thread 2 calls get_and_increment: increments the counter to 1, returns 0, therefore fail to create a new session client

Thread 3 calls get_and_increment: increments the counter to 2, returns 1, allowing a new session client to be create with a closed session.

The knowledge of a live session must be composed by its ref count plus a flag that tells you if the session was closed already.

I understand you reasoning but, if decrement returns 0 means that no other client is holding this session anymore, also, at this point, if __del__ gets called means that this client is being garbage collected, hence, no client could possibly call new_session_client.

You're right. Thread 1 would not decrement to zero if thread 2 and 3 are holding a client. Ignore me. :)

ashfire908 · 2016-11-03T19:43:59Z

faunadb/client.py

-    except:
-      pass
+    if self.counter.decrement() == 0:
+      try:


This try/except block was to attempt to handle some weird corner that came up in testing (I think it was when a test failed?), it's not a proper fix, and should be removed if possible.

yeah, I really wanted to remove this but I was afraid to do, though, I removed and no exception was thrown

marrony · 2016-11-07T13:36:17Z

Can I have another review on this PR?

erickpintor

LGTM. Just a little question.

erickpintor · 2016-11-07T14:20:04Z

faunadb/client.py

-    })
-    self.session.timeout = timeout
-
+    self.auth = HTTPBasicAuth(secret, "")


Just to confirm: is this base64 encrypted?

erickpintor reviewed Oct 25, 2016

View reviewed changes

ashfire908 reviewed Oct 25, 2016

View reviewed changes

marrony force-pushed the new_session_client branch from a503d9f to 1ef0bde Compare October 26, 2016 00:00

marrony commented Oct 26, 2016

View reviewed changes

erickpintor reviewed Oct 26, 2016

View reviewed changes

marrony force-pushed the new_session_client branch from 1ef0bde to 5187682 Compare November 2, 2016 21:51

adds new_session_client method

5a6cf05

marrony force-pushed the new_session_client branch from 5187682 to 5a6cf05 Compare November 3, 2016 15:46

erickpintor reviewed Nov 3, 2016

View reviewed changes

marrony added 2 commits November 3, 2016 17:18

fix possible thread racing when creating new session clients

3d5c403

adds parameters to configure number of connections to pool

a9ffffe

marrony force-pushed the new_session_client branch from ed07d7e to a9ffffe Compare November 3, 2016 19:19

ashfire908 reviewed Nov 3, 2016

View reviewed changes

remove unnecessary try/catch

a6c77bc

erickpintor approved these changes Nov 7, 2016

View reviewed changes

marrony merged commit 949c811 into master Nov 7, 2016

marrony deleted the new_session_client branch November 7, 2016 15:42

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

adds new_session_client method #100

adds new_session_client method #100

marrony commented Oct 24, 2016 •

edited

Loading

erickpintor Oct 25, 2016

marrony Oct 25, 2016

ashfire908 Oct 25, 2016

marrony Oct 25, 2016

ashfire908 Oct 25, 2016

marrony Oct 25, 2016

ashfire908 Oct 25, 2016

marrony Oct 26, 2016

erickpintor Oct 26, 2016

ashfire908 Oct 26, 2016

erickpintor Oct 26, 2016

ashfire908 Oct 26, 2016

erickpintor Oct 26, 2016

ashfire908 Oct 26, 2016

erickpintor Oct 27, 2016

marrony Oct 27, 2016

erickpintor Oct 28, 2016

erickpintor Oct 26, 2016

erickpintor Oct 26, 2016

codecov-io commented Nov 3, 2016 •

edited

Loading

erickpintor Nov 3, 2016

marrony commented Nov 3, 2016

erickpintor commented Nov 3, 2016

erickpintor Nov 3, 2016

erickpintor Nov 3, 2016

marrony Nov 3, 2016

erickpintor Nov 3, 2016

ashfire908 Nov 3, 2016

marrony Nov 3, 2016

marrony commented Nov 7, 2016

erickpintor left a comment

erickpintor Nov 7, 2016

marrony Nov 7, 2016

adds new_session_client method #100

adds new_session_client method #100

Conversation

marrony commented Oct 24, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codecov-io commented Nov 3, 2016 • edited Loading

Current coverage is 99.79% (diff: 97.22%)

Choose a reason for hiding this comment

marrony commented Nov 3, 2016

erickpintor commented Nov 3, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

marrony commented Nov 7, 2016

erickpintor left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

marrony commented Oct 24, 2016 •

edited

Loading

codecov-io commented Nov 3, 2016 •

edited

Loading