On 04:56 pm, twisted-pyt...@2xlp.com wrote:
there doesn't seem to be a way to access the connection objects within
the pool ( psycopg2 manages this via
`connection.set_isolation_level(X)`
Basically. There is a trick to work around this, invent your own DB-API
2.0 wrapper around psycopg2 that
On 02:57 pm, ga...@gromper.net wrote:
Hi,
We're using AMP and are starting to hit TooLong errors when scaling
our application. In one respect it's a sign that we should do
something like paging large requests and responses, but that's a lot
more work, and comes with its own problems. We also don
>> I've put in the dataReceived, and the answer box does*not*make it
>> into the Protocol. There are two entries in
>> protocol._outstandingRequests: {'2189': , '2188':
>> } and the log output shows 2186, 2187, 218a, 218b, ...
>
> So, wait a second.
>
> You said you're looking at tcpdump, and it'
there doesn't seem to be a way to access the connection objects within the pool
( psycopg2 manages this via `connection.set_isolation_level(X)`
the only workaround I can think of seems to be emitting raw sql when I first
start the transaction - but this doesn't seem right.
am i missing anything
> On Nov 13, 2014, at 3:40 PM, Peter Westlake wrote:
>
> I'm certainly not averse to understanding the code, and if you had time to
> describe it, that would be very kind, thank you!
Well if it's not even hitting dataReceived then a more subtle exploration is
not necessary! ;-)
> I've put in
Hi,
We're using AMP and are starting to hit TooLong errors when scaling
our application. In one respect it's a sign that we should do
something like paging large requests and responses, but that's a lot
more work, and comes with its own problems. We also don't need
particularly large payloads: rig
On Thu, 13 Nov 2014, at 13:17, Glyph wrote:
>
>> On Nov 13, 2014, at 1:15 PM, Peter Westlake
>> wrote:
>>
>> I've had a look at the code, and got rather lost amongst the
>> interfaces and inheritance and protocols and transports. If someone
>> can help me narrow down the relevant bits of code, I
> On Nov 13, 2014, at 1:15 PM, Peter Westlake wrote:
>
> I've had a look at the code, and got rather lost amongst the interfaces
> and inheritance and protocols and transports. If someone can help me
> narrow down the relevant bits of code, I can put in some Python tracing.
>
I could describe
TL;DR - how do I debug the sequence of events between an AMP answer box
arriving at a NIC, and AMP firing the callRemote Deferred?
I have an application with two processes, on separate machines,
communicating using AMP. One process does a callRemote, which returns a
Deferred, which is never fired.
