gmane.comp.python.tornado

Re: Re: Tornado Encookie - Encrypted Cookies

Aleksey Silk — 2013-05-20T12:33:19

I didin't delete previous cookie. Now everything works fine.

С уважением, Алексей Силк
With best regards, Aleksey Silk

+7 (981) 849-12-36
aleksey-+9577CgJpo0< at >public.gmane.org
skype - rootiks



2013/5/20 Алексей Силк <aleksey-+9577CgJpo0< at >public.gmane.org>

Re: Memory leak in 3.0.1?

Serge S. Koval — 2013-05-20T11:55:33

Submitted pull request.

Still, not convinced it is necessary - this situation can only happen in
recursive calls and python developers know that python does not do any
call-tail optimization.

Anyway, performance-wise it is not that bad. Two tests with 50 nested
StackContexts and ExceptionStackContexts:

Current 3.0:

(tornado)serge< at >Cheetah ~/Work/tornado/prj> python -m timeit -n 10000 -s
"import bench; import old_stack as stack_context" "bench.stacked(50,
stack_context)"
10000 loops, best of 3: 359 usec per loop

(tornado)serge< at >Cheetah ~/Work/tornado/prj> python -m timeit -n 10000 -s
"import bench; import old_stack as stack_context" "bench.stacked_exc(50,
stack_context)"
10000 loops, best of 3: 368 usec per loop


Current master (without stack deactivation):

(tornado)serge< at >Cheetah ~/Work/tornado/prj> python -m timeit -s "import
bench; import new_stack as stack_context" "bench.stacked(50, stack_context)"
10000 loops, best of 3: 128 usec per loop

(tornado)serge< at >Cheetah ~/Work/tornado/prj> python -m timeit

Re: Tornado Encookie - Encrypted Cookies

Алексей Силк — 2013-05-20T11:50:33

    Traceback (most recent call last):
      File "/var/www/myftpbackup/tornado/web.py", line 1055, in 
_stack_context_handle_exception
        raise_exc_info((type, value, traceback))
      File "/var/www/myftpbackup/tornado/web.py", line 1178, in wrapper
        result = method(self, *args, **kwargs)
      File "/var/www/myftpbackup/classes/indexall.py", line 39, in get
        ppKwargs = self.indexPageRun()
      File "/var/www/myftpbackup/classes/indexall.py", line 16, in 
indexPageRun
        ppUser = self.encookie.get_secure_cookie('user'),
      File "/var/www/myftpbackup/tornadoencookie/encookie.py", line 53, in 
get_secure_cookie
        return self._decrypt(encrypted_value.decode('utf-8'))
      File "/var/www/myftpbackup/tornadoencookie/encookie.py", line 29, in 
_decrypt
        return 
self.cipher.decrypt(base64.b64decode(value.encode('utf-8'))).decode('utf-8').rstrip(self.PADDING)
      File "/usr/lib/python2.7/base64.py", line 76, in b64decode
        raise TypeError(msg)
    TypeError: Incorr

Re: 'EPollIOLoop' object has no attribute 'run_sync'

Drasko DRASKOVIC — 2013-05-20T01:28:24

Whoops, sorry, I did not have version 3.0.

Updated, now works fine.

BR,
Drasko

On Mon, May 20, 2013 at 3:11 AM, Drasko DRASKOVIC
<drasko.draskovic-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

'EPollIOLoop' object has no attribute 'run_sync'

Drasko DRASKOVIC — 2013-05-20T01:11:53

Hi all,
I am tying to use IOLoop's tun_rsync() method 
(http://www.tornadoweb.org/en/stable/ioloop.html#tornado.ioloop.IOLoop.run_sync), 
and I want something exactly like described here :

https://groups.google.com/forum/?fromgroups#!msg/python-tornado/o4kZofepfr4/OmAsKpJVQ6YJ

However, trying this example is giving me an error :

Traceback (most recent call last):
  File "test2.py", line 19, in <module>
    tornado.ioloop.IOLoop.instance().run_sync(main)
AttributeError: 'EPollIOLoop' object has no attribute 'run_sync'

What seems to be wrong and how to debug this ?

Best regards,
Drasko

Re: Re: Motor and get_current_user(), async for prepare()

A. Jesse Jiryu Davis — 2013-05-19T23:23:05

Thanks, that's very useful.


On Sun, May 19, 2013 at 6:25 AM, Meir Kriheli <mkriheli-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: Sending responses via other handler's route (url)

Serge S. Koval — 2013-05-19T19:21:06

On Sun, May 19, 2013 at 9:26 PM, Drasko DRASKOVIC <
drasko.draskovic-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

That's correct. Shoudn't be global variable - can be static variable in a
class.


They live in python process. But they know nothing about each other.


No, there's no global state variable that stores all open connections.

This was done like this for few reasons:
1. sockjs-tornado cannot assume how application will want to group clients.
Chat app might want to group by rooms. IM might want to have global list of
users. Some sort of radio website - by some token sent from the page, etc.
2. You might want to scale your application beyond single server setup. In
this case, you'll need some sort of meeting point (say, redis), to manage
connections between two servers. Global variable no longer works.

In your case, having one global variable for all opened connections won't
really help: you will have ReqConnection and RspConnection in same place
and will have to do filtering when broadcasting.

Re: Sending responses via other handler's route (url)

Drasko DRASKOVIC — 2013-05-19T18:26:18

Hi Serge,

On Sun, May 19, 2013 at 6:42 PM, Serge S. Koval <serge.koval-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Yes, indeed. Thanks for this explanation.

So, as I understand, the connected client object is present only in
RspConnection hadler class, and I can not get it otherwise, but
getting it as `self` in this handler, then storing it in a global
variable.

But that seems strange, because if there is 5 RspConnection object
instances, as you mentioned, where do they "live" ?
They must be somewhere in the Tornado structures, during the time the
connection is opened and object is sitll "alive" (valid).

I thought that would be easier to fetch them from there, rather that
storing their reference in the global variable at one specific point.
But I have been greping through the code for hours and I still can not
find where these RspConnection objects are instanciated and kept once
connection had been opened and they are created.

BR,
Drasko

Re: Sending responses via other handler's route (url)

Serge S. Koval — 2013-05-19T16:42:32

Every incoming sockjs connection is instance of the appropriate connection
class. So, if you have 5 connected clients to RspConnection endpoint, there
will be 5 RspConnection object instances. Also, `self` in RspConnection can
be used to store data for the connection - it is unique for every connected
client.

sockjs-tornado does not keep list of connected clients - you need to manage
this list by yourself (add/remove items in on_open/on_close).

So, as I wrote before - feel free to organize clients way you want and use
broadcast to send messages. You can also check chat example:
https://github.com/mrjoes/sockjs-tornado/tree/master/examples/chat

Hope it helps.


On Sun, May 19, 2013 at 7:22 PM, Drasko DRASKOVIC <
drasko.draskovic-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: Sending responses via other handler's route (url)

Drasko DRASKOVIC — 2013-05-19T16:22:01

Hi Serge,

On Sun, May 19, 2013 at 5:08 PM, Serge S. Koval <serge.koval-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

What I meant is calling some internal tornado-sockjs function to get
that client object.

For example, this will not work :
class ReqConnection(SockJSConnection):
    def on_message(self, msg):
        logging.info("REQ handshake successful")
        RspConnection.send(msg)

It will give this error :
TypeError: unbound method send() must be called with RspConnection
instance as first argument (got str instance instead)

I am not sure why send() must be called with RspConnection instance as
first argument.

But if at this point I can have a getter function to get me a correct
instance X of RspConnection class, then I can call X.send(mesg), I
thing. So I thought that Tornado keeps a list of these connection
instances (handlers) somewhere and that I can get them and call their
send() function (instead calling self.send() of the current - in this
case REQ - handler).

BR,
Drasko

Re: Sending responses via other handler's route (url)

Serge S. Koval — 2013-05-19T15:08:46

Not sure I understand what is the problem

sockjs-tornado does not do any kind of client grouping - you have to do it
yourself.

Simplest way possible: have global variable (like you have). Make it set.

In RspConnection.on_open add self to the set. In RspConnection.on_close
remove it from the set.

In ReqConnection.on_message to self.broadcast(rsp, msg)

That's it.




On Sun, May 19, 2013 at 4:52 PM, Drasko DRASKOVIC <
drasko.draskovic-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: Sending responses via other handler's route (url)

Drasko DRASKOVIC — 2013-05-19T13:52:55

Hi Serge,

On Sunday, May 19, 2013 10:43:44 AM UTC+2, Serge S. Koval wrote:
 
My problem is how to get this RSP instance, so that I can call it from REQ 
handler. 
Can I somehow get the RSP connection instance by providing corresponding 
"/rsp" route ?

So far I came up with this :

from tornado import web, ioloop
from sockjs.tornado import SockJSRouter, SockJSConnection

rsp = 0

class ReqConnection(SockJSConnection):
    def on_message(self, msg):
        global rsp
        logging.info("REQ handshake successful")
        rsp.send(msg)
 

    def on_open(self, info):
        logging.info("REQ_ON_OPEN")

class RspConnection(SockJSConnection):
    def on_message(self, msg):
        logging.info("RSP andshake successful")

    def on_open(self, info):
        global rsp 
        rsp = self


if __name__ == '__main__':
    import logging
    logging.getLogger().setLevel(logging.DEBUG)

    ReqRouter = SockJSRouter(ReqConnection, '/req')
    RspRouter = SockJSRouter(RspConnection, '/rsp')

    app = web.Applic

Re: Sending responses via other handler's route (url)

Drasko DRASKOVIC — 2013-05-19T13:47:01

Hi Lorenzo,

On Sunday, May 19, 2013 10:09:06 AM UTC+2, Lorenzo Bolla wrote:

I am not sure what you meant here... How are you instanciating 
BaseConnection(), in order to call it's write() method ?

This is exactly my problem, as BaseConnection calss is inherited from 
SockJSConnection(), but I have no idea where these are instantiated. I need 
and instance of BaseConnection class in ReqConnection.on_message() 
function, in order to call BaseConnection.your_write().

Can you please give an functional example to ilustrate this ?

BR,
Drasko

Re: Re: Motor and get_current_user(), async for prepare()

Meir Kriheli — 2013-05-19T10:25:20

Looks like it's related to this bug:
https://github.com/python-greenlet/greenlet/issues/28

As mentioned, installed from master, but still (non-consistent) segfaults.

Cheers


On Sun, May 19, 2013 at 10:46 AM, Meir Kriheli <mkriheli-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: Sending responses via other handler's route (url)

Serge S. Koval — 2013-05-19T08:43:44

Sure you can. Just keep set of RSP connection instances somewhere and use
broadcast to send to them from REQ instances.


On Sun, May 19, 2013 at 11:09 AM, Lorenzo Bolla <lbolla-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: Sending responses via other handler's route (url)

Lorenzo Bolla — 2013-05-19T08:09:06


I'd say that the best way to handle this is to create a separate method, and
use it in both your classes. You could put the common function at the module
level, or make it a method of a common base class. Something like:


hth,
L.

Re: Re: Motor and get_current_user(), async for prepare()

Meir Kriheli — 2013-05-19T07:46:03

Hi Jesse,

Nope, no resolution. I've noticed that greenlet had some updates to their
git repo for gcc 4.8 (that's what ArchLinux carries this days), tried that
too, didn't help.

I'm suspecting g_handle_exit<https://github.com/python-greenlet/greenlet/blob/master/greenlet.c#L656>()
at greenlet.c as it deson't check just for NULL without PyExc_GreenletExit
(which maybe something abnormal, but looks like it happens), but nothing
definitive yet.

Cheers


On Sat, May 18, 2013 at 5:38 PM, A. Jesse Jiryu Davis <jesse-xWyci+YBle0R/ETfKvJy3A< at >public.gmane.orgt

Re: Motor and PyMongo versions

Jorge Puente Sarrín — 2013-05-19T04:41:13

Yep, It's true. Toro 0.4 is there, but its source code no.

kubuntu< at >puentesarrin:~$ pip install toro==0.4
Downloading/unpacking toro==0.4
  Could not find a version that satisfies the requirement toro==0.4 (from
versions: )
No distributions matching the version for toro==0.4
Storing complete log in /home/puentesarrin/.pip/pip.log


On Sat, May 18, 2013 at 3:21 PM, A. Jesse Jiryu Davis <jesse-xWyci+YBle0R/ETfKvJy3A< at >public.gmane.orgt

Sending responses via other handler's route (url)

Drasko DRASKOVIC — 2013-05-19T02:01:54

Hi all,
I was wondering is it possible from one handler to write to another route, 
i.e. to call another handler's class write() ?
This way I can receiver requests via /req, but answer them via /rsp.

Something like this : 

from tornado import web, ioloop
from sockjs.tornado import SockJSRouter, SockJSConnection

class ReqConnection(SockJSConnection):
    def on_message(self, msg):
       logging.info("REQ handshake successful")
       RspConnection(SockJSConnection).send(msg)

    def on_open(self, info):
 logging.info("REQ_ON_OPEN")

class RspConnection(SockJSConnection):
    def on_message(self, msg):
       logging.info("RSP andshake successful")

    def on_open(self, info):
 logging.info("RSP_ON_OPEN")


if __name__ == '__main__':
    import logging
    logging.getLogger().setLevel(logging.DEBUG)

    ReqRouter = SockJSRouter(ReqConnection, '/req')
    RspRouter = SockJSRouter(RspConnection, '/rsp')

    app = web.Application(ReqRouter.urls, RspRouter.urls)
    app.listen(8081)

    logging.info(" [*]

Re: raise tornado.web.HTTPError

funback — 2013-05-18T19:40:39

Thank you guys! Enabling proxy_intercept_errors at the server level 
resolves the problem.

On Thursday, May 16, 2013 11:56:30 AM UTC+8, funback wrote:

Re: Memory leak in 3.0.1?

Ben Darnell — 2013-05-18T19:07:20


I'd also consider a solution specific to gen.engine/coroutine, since I
believe those are the only places the deactivation callback was ever used.
 Stack contexts are kind of a poor fit for the coroutine error handling
case, and before you made nested stack contexts less expensive I was
planning to look into using them less.  When you yield a Future you don't
need a stack context at all because the Future encapsulates its error
status.  Tasks could start their own stack context instead of relying on a
context from the surrounding coroutine.  The one thing I'm not sure of is
the Callback/Wait pattern - people could be relying on a stack context
being present when they call the thing that they pass the Callback to.  We
could perhaps have the gen.Runner decide on a segment-by-segment basis
whether a stack context is needed (based on whether there are outstanding
Callbacks), but that seems complicated.  Maybe as Futures become more
widespread we can phase out Callback/Wait.

-Ben