In general, I'm finding a bit tricky dealing with Tornado's async'ness. For example, I did a quick runtime patch of boto python library to use S3, but it won't work transparently across the whole library. I now want to use to Google AdWords python API, but they use SOAPpy and to my knowledge they don't provide a good way to get a custom URLConnection.
Is everyone porting their libraries to use Tornado's HTTP client or moving those functions to other servers that can handle threads?
-Elias Torres
By IOStream, I mean
http://github.com/facebook/tornado/blob/master/tornado/iostream.py.
IOStream is a class that will help you create Asynchronous clients,
which you could use for instance to create a memcache client, or a
SOAP client.
> In general, I'm finding a bit tricky dealing with Tornado's async'ness. For example, I did a quick runtime patch of boto python library to use S3, but it won't work transparently across the whole library. I now want to use to Google AdWords python API, but they use SOAPpy and to my knowledge they don't provide a good way to get a custom URLConnection.
>
> Is everyone porting their libraries to use Tornado's HTTP client or moving those functions to other servers that can handle threads?
I'm not even sure how many people are actually using tornado in the
wild. Obviously FriendFeed, and of course there was an article just
recently (http://agiletesting.blogspot.com/2009/12/deploying-tornado-in-production.html)
from a guy at Evite.
But, I haven't seen too many announcements on the list saying, "We've
just released an async library for X." So, my assumptions are that
they just let everything block... I know that the things I'm using
tornado for are in conjunction with MongoDB (nothing in production
yet) and I'm just letting it block. I guess it all depends...
> On Dec 21, 2009, at 5:50 PM, Andrew Gwozdziewycz wrote:
>
>> Judging by the FriendFeed view of using blocking MySQL, I'd say they
>> most likely didn't fuss with it, though I can't confirm it. I would
>> think there'd need to a client built for the Tornado IOLoop to do
>> this, but, maybe it wouldn't be too hard to wrap IOStream around the
>> client?
>>
>> On Fri, Dec 11, 2009 at 8:07 PM, Elias Torres <el...@torrez.us> wrote:
>>> In Tornado we want to minimize blocking in general. I just started my application, but was wondering if moving to memcached is enough or should I be using the non-blocking features of memcache? I'm not sure if those are exposed via the python wrapper (at least mget) although set, add, delete are already available by setting the proper behaviors based on a quick code inspection.
>>>
>>> Did FriendFeed guys use memcache async clients or not?
>>>
>>> -Elias
>>
>>
>>
>> --
>> http://www.apgwoz.com
>
>
On 22 Грд, 13:15, Andrew Gwozdziewycz <apg...@gmail.com> wrote:
> On Mon, Dec 21, 2009 at 10:25 PM, Elias Torres <el...@torrez.us> wrote:
> > Thanks Andrew. Could you clarify what you mean by wrapping IOStream?
>
> By IOStream, I meanhttp://github.com/facebook/tornado/blob/master/tornado/iostream.py.
> IOStream is a class that will help you create Asynchronous clients,
> which you could use for instance to create a memcache client, or a
> SOAP client.
>
> > In general, I'm finding a bit tricky dealing with Tornado's async'ness. For example, I did a quick runtime patch of boto python library to use S3, but it won't work transparently across the whole library. I now want to use to Google AdWords python API, but they use SOAPpy and to my knowledge they don't provide a good way to get a custom URLConnection.
>
> > Is everyone porting their libraries to use Tornado's HTTP client or moving those functions to other servers that can handle threads?
>
> I'm not even sure how many people are actually using tornado in the
> wild. Obviously FriendFeed, and of course there was an article just
> recently (http://agiletesting.blogspot.com/2009/12/deploying-tornado-in-product...)