On Dec 14, 2011, at 7:38 PM, Augusto Mecking Caringi wrote:
> On Wed, Dec 14, 2011 at 9:49 PM, Andrew Bennetts
> wrote:
>> Augusto Mecking Caringi wrote:
>> om[3082188716].c
>> […]
>>> str(2917687304
>>> 53120905B 1par 'ype: Test\nDate: 2011-12-14
>>> 16:45:30.995217\nEvent-Subtype: FooBar\
On Wed, Dec 14, 2011 at 9:49 PM, Andrew Bennetts wrote:
> Augusto Mecking Caringi wrote:
>> >>> om[3082188716].c
> […]
>> str(2917687304
>> 53120905B 1par 'ype: Test\nDate: 2011-12-14
>> 16:45:30.995217\nEvent-Subtype: FooBar\nContent-Type:
>> application/json\n\n{\n ')
>
> So it appears you have
On 08:34 pm, augustocari...@gmail.com wrote:
On Sun, Dec 11, 2011 at 5:11 PM, wrote:
On 10 Dec, 05:25 pm, augustocari...@gmail.com wrote:
On Fri, Dec 9, 2011 at 7:31 PM, Itamar Turner-Trauring
wrote:
What's the best solution? Apply the patch attached on this
ticket,
moving to a prod
Augusto Mecking Caringi wrote:
> >>> om[3082188716].c
[…]
> str(2917687304
> 53120905B 1par 'ype: Test\nDate: 2011-12-14
> 16:45:30.995217\nEvent-Subtype: FooBar\nContent-Type:
> application/json\n\n{\n ')
So it appears you have 53 megabyte string that's referenced from your TLS
connection, presum
On Sun, Dec 11, 2011 at 5:11 PM, wrote:
> On 10 Dec, 05:25 pm, augustocari...@gmail.com wrote:
>>
>> On Fri, Dec 9, 2011 at 7:31 PM, Itamar Turner-Trauring
>> wrote:
What's the best solution? Apply the patch attached on this ticket,
moving to a producer/consumer approach, or a
On 10 Dec, 05:25 pm, augustocari...@gmail.com wrote:
On Fri, Dec 9, 2011 at 7:31 PM, Itamar Turner-Trauring
wrote:
What's the best solution? Apply the patch attached on this
ticket,
moving to a producer/consumer approach, or any other idea?
The patch will just delay the problem... you're
On Fri, Dec 9, 2011 at 7:31 PM, Itamar Turner-Trauring
wrote:
>> What's the best solution? Apply the patch attached on this ticket,
>> moving to a producer/consumer approach, or any other idea?
>
> The patch will just delay the problem... you're creating a huge number of
> strings, faster than
> What's the best solution? Apply the patch attached on this ticket,
> moving to a producer/consumer approach, or any other idea?
The patch will just delay the problem... you're creating a huge number of
strings, faster than the transport can write them out. The solution is
indeed to use the c
Hi!
I'm writing a software using Python Twisted with the following architecture:
[server]<->[providers]
The providers (that can be thousands) send events to the
centralized server, usually we have a few events per minute for each
provider, but a burst of events can happen.
So I
