On Wed, Jan 14, 2015 at 12:54 PM, Philip Martin
wrote:
> Lieven Govaerts writes:
>
>> The easiest way is to use existing tests as a starting point.:
>> - Test test_serf_connection_request_create sends 2 requests and responses.
>> This tests sends two pipelined requests, but you can modifiy it t
Lieven Govaerts writes:
> The easiest way is to use existing tests as a starting point.:
> - Test test_serf_connection_request_create sends 2 requests and responses.
> This tests sends two pipelined requests, but you can modifiy it to
> send the 1st request, then run the serf loop, then send th
Philip Martin writes:
> $ valgrind -q test/test_all
> ==11901== Invalid read of size 8
> ==11901==at 0x403E7CF: serf_config_get_object (config_store.c:278)
> ==11901==by 0x403F88A: serf__log (logging.c:146)
> ==11901==by 0x4048E79: serf_log_wrapped_readline
> (log_wrapper_buckets.c:5
Philip Martin writes:
> Lieven Govaerts writes:
>
>> Is there a reason you specifically mention pipelined here? The first
>> response has been handled so it's just synchronous communication.
>
> The point is that the client reads data from the server before sending
> the second response. If the
Lieven Govaerts writes:
> On Mon, Jan 12, 2015 at 12:22 PM, Philip Martin
>>
>> I'm not familiar with serf's testsuite. The scenario:
>>
>> - client sends first request
>> - server sends response
>> - server sends extra data, say '\n'
>> - client handles first request
>> - client creat
On Mon, Jan 12, 2015 at 12:22 PM, Philip Martin
wrote:
> Lieven Govaerts writes:
>
>> You're trying to capture the situation where serf has:
>> - finished writing a request ( req_bkt == NULL && writing_started )
>> - has no more requests in the pending queue
>> - and receives actual bytes of data
Lieven Govaerts writes:
> You're trying to capture the situation where serf has:
> - finished writing a request ( req_bkt == NULL && writing_started )
> - has no more requests in the pending queue
> - and receives actual bytes of data.
> Right?
>
> Looks like your patch is a correct way to fix th
Hi,
On Sat, Jan 10, 2015 at 1:07 PM, Philip Martin
wrote:
> Philip Martin writes:
>
>> Philip Martin writes:
>>
>>> While debugging a problem reported on users I accidentally sent an extra
>>> byte to the client: I sent Content-Length of N and then sent N+1 bytes.
>>> The first N bytes made a
Philip Martin writes:
> Philip Martin writes:
>
>> While debugging a problem reported on users I accidentally sent an extra
>> byte to the client: I sent Content-Length of N and then sent N+1 bytes.
>> The first N bytes made a valid response, so serf was happy at that
>> stage. When processing
Philip Martin writes:
> While debugging a problem reported on users I accidentally sent an extra
> byte to the client: I sent Content-Length of N and then sent N+1 bytes.
> The first N bytes made a valid response, so serf was happy at that
> stage. When processing the next request the extra byte
Philip Martin writes:
> Index: buckets/response_buckets.c
> ===
> --- buckets/response_buckets.c(revision 2445)
> +++ buckets/response_buckets.c(working copy)
> @@ -129,7 +129,10 @@ static apr_status_t parse_status_li
writes:
>> I noticed that your proxy is changing the status line by dropping the
>> reason-phrase:
>>
>>HTTP/1.1 207 Multi-Status
>>
>> to
>>
>>HTTP/1.1 207
> Good news! I could create a new implementation of the JDK HttpServer
> which fixes the 207 Status line problem, and I can't r
While debugging a problem reported on users I accidentally sent an extra
byte to the client: I sent Content-Length of N and then sent N+1 bytes.
The first N bytes made a valid response, so serf was happy at that
stage. When processing the next request the extra byte causes serf to
attempt to handl
On Jun 24, 2011 5:02 PM, "Stefan Sperling" wrote:
>
> On Fri, Jun 24, 2011 at 01:55:13PM -0400, Greg Stein wrote:
> > Yeah, that was fixed a week or two ago on trunk (I assume you're using
> > 0.7.2?)
>
> I'm using 0.7.x from a few days ago.
>
> I'll try to update to serf trunk. I suppose serf tru
[Stefan Sperling]
> I'll try to update to serf trunk. I suppose serf trunk will become
> serf 1.0 and we should all be testing with trunk at this point
> rather than 0.7.x?
Note if you do update to serf trunk, you'll need to patch
build/ac-macros/serf.m4:
http://svn.haxx.se/dev/archive-2011-
On Fri, Jun 24, 2011 at 01:55:13PM -0400, Greg Stein wrote:
> Yeah, that was fixed a week or two ago on trunk (I assume you're using
> 0.7.2?)
I'm using 0.7.x from a few days ago.
I'll try to update to serf trunk. I suppose serf trunk will become
serf 1.0 and we should all be testing with trunk a
On Fri, Jun 24, 2011 at 11:08 AM, Greg Stein wrote:
>> You can disable wire compression in your server config file.
>
> On the client side.
http-compression = no
HTH. -- justin
On Jun 24, 2011 2:07 PM, "Greg Stein" wrote:
>
>
> On Jun 24, 2011 1:57 PM, "Daniel Shahaf" wrote:
> >
> > Philip Martin wrote on Fri, Jun 24, 2011 at 18:50:59 +0100:
> > > Daniel Shahaf writes:
> > >
> > > > ==15085== Conditional jump or move depends on uninitialised value(s)
> > > > ==15085==
On Jun 24, 2011 1:57 PM, "Daniel Shahaf" wrote:
>
> Philip Martin wrote on Fri, Jun 24, 2011 at 18:50:59 +0100:
> > Daniel Shahaf writes:
> >
> > > ==15085== Conditional jump or move depends on uninitialised value(s)
> > > ==15085==at 0x4629A2E: inflateReset2 (in /usr/lib/libz.so.1.2.3.4)
> >
Daniel Shahaf writes:
> Philip Martin wrote on Fri, Jun 24, 2011 at 18:50:59 +0100:
>> zlib doesn't play well with valgrind, see for example:
>>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=287603
>>
>> so this may be a false positive.
>
> Can I disable all forms of compression that migh
Philip Martin wrote on Fri, Jun 24, 2011 at 18:50:59 +0100:
> Daniel Shahaf writes:
>
> > ==15085== Conditional jump or move depends on uninitialised value(s)
> > ==15085==at 0x4629A2E: inflateReset2 (in /usr/lib/libz.so.1.2.3.4)
> > ==15085==by 0x4629B0C: inflateInit2_ (in /usr/lib/libz.
Yeah, that was fixed a week or two ago on trunk (I assume you're using
0.7.2?)
On Jun 24, 2011 1:28 PM, "Stefan Sperling" wrote:
> I don't know if this is already known, so I am reporting it
> here to get confirmation.
>
> (From #svn-dev):
> run svn log --diff -r1139384 for fun
> with serf
> Ct
Daniel Shahaf writes:
> ==15085== Conditional jump or move depends on uninitialised value(s)
> ==15085==at 0x4629A2E: inflateReset2 (in /usr/lib/libz.so.1.2.3.4)
> ==15085==by 0x4629B0C: inflateInit2_ (in /usr/lib/libz.so.1.2.3.4)
> ==15085==by 0x428E453: serf_deflate_read (deflate_bu
Stefan Sperling wrote on Fri, Jun 24, 2011 at 19:27:44 +0200:
> I don't know if this is already known, so I am reporting it
> here to get confirmation.
>
> (From #svn-dev):
> run svn log --diff -r1139384 for fun
> with serf
> Ctrl-C out in the middle when it prints diff text
> -> core dump
>
On Fri, Jun 24, 2011 at 07:27:44PM +0200, Stefan Sperling wrote:
> I don't know if this is already known, so I am reporting it
> here to get confirmation.
>
> (From #svn-dev):
> run svn log --diff -r1139384 for fun
> with serf
> Ctrl-C out in the middle when it prints diff text
> -> core dump
I don't know if this is already known, so I am reporting it
here to get confirmation.
(From #svn-dev):
run svn log --diff -r1139384 for fun
with serf
Ctrl-C out in the middle when it prints diff text
-> core dump
#0 0x000204cef469 in destroy_request (request=0x2083f47b8)
at ./outgoi
On Sun, Feb 21, 2010 at 07:22:36AM -0800, Justin Erenkrantz wrote:
> On Sun, Feb 21, 2010 at 2:49 AM, Stefan Sperling wrote:
> > Hi,
> >
> > I accidentally ended up using ra_serf today (have been using ra_neon
> > mostly cause ra_serf has been quite unstable). And, surprise,
> > it promptly crashe
On Sun, Feb 21, 2010 at 2:49 AM, Stefan Sperling wrote:
> Hi,
>
> I accidentally ended up using ra_serf today (have been using ra_neon
> mostly cause ra_serf has been quite unstable). And, surprise,
> it promptly crashed on me in all its glory. See below.
>
> Note that the trunk build I was using
Stefan Sperling writes:
> Segmentation fault (core dumped)
> #0 cancel_request (request=0x20eac04b8, list=0x2063fb078, notify_request=0)
> at context.c:440
> 440 serf_debug__closed_conn(request->req_bkt->allocator);
> (gdb) bt
> #0 cancel_request (request=0x20eac04b8, list=0x2063f
Hi,
I accidentally ended up using ra_serf today (have been using ra_neon
mostly cause ra_serf has been quite unstable). And, surprise,
it promptly crashed on me in all its glory. See below.
Note that the trunk build I was using was a bit outdated (ca. 19th of
December 2009), so this may have been
30 matches
Mail list logo
