Cool info… I'm (painfully) building Jenkins here locally and will
try to get a bt on the actual scenario…
On Nov 8, 2011, at 11:00 AM, Jeff Trawick wrote:
> On Tue, Nov 8, 2011 at 9:37 AM, Jim Jagielski wrote:
>> Here is the method for the Jenkins CLI that causes all the sadness.
>> The major se
On Tue, Nov 8, 2011 at 11:00 AM, Jeff Trawick wrote:
> On Tue, Nov 8, 2011 at 9:37 AM, Jim Jagielski wrote:
>> Here is the method for the Jenkins CLI that causes all the sadness.
>> The major section is this:
>
> Thanks for the testcase!
>
> The EAGAIN is getting generated from here:
>
> static a
On Tue, Nov 8, 2011 at 9:37 AM, Jim Jagielski wrote:
> Here is the method for the Jenkins CLI that causes all the sadness.
> The major section is this:
Thanks for the testcase!
The EAGAIN is getting generated from here:
static apr_status_t get_remaining_chunk_line(http_ctx_t *ctx,
Here is the method for the Jenkins CLI that causes all the sadness.
The major section is this:
con.getOutputStream().close();
input = con.getInputStream();
// make sure we hit the right URL
if(con.getHeaderField("Hudson-Duplex")==null)
throw new IOExcept
SSL isn't involved, no.
On Nov 7, 2011, at 4:28 PM, Jeff Trawick wrote:
> On Tue, Nov 1, 2011 at 1:23 PM, Jim Jagielski wrote:
>> In mod_proxy_http we have:
>>
>>/* Prefetch MAX_MEM_SPOOL bytes
>> *
>> * This helps us avoid any election of C-L v.s. T-E
>> * request bodies, since
On Tue, Nov 1, 2011 at 1:23 PM, Jim Jagielski wrote:
> In mod_proxy_http we have:
>
> /* Prefetch MAX_MEM_SPOOL bytes
> *
> * This helps us avoid any election of C-L v.s. T-E
> * request bodies, since we are willing to keep in
> * memory this much data, in any case. This gives
Will try to do before traveling to AC...
On Nov 4, 2011, at 9:10 PM, Jeff Trawick wrote:
> On Fri, Nov 4, 2011 at 4:14 PM, Jim Jagielski wrote:
>>
>> On Nov 4, 2011, at 4:23 AM, Rüdiger Plüm wrote:
>>
>>>
>>>
>>> Am 03.11.2011 20:00, schrieb Jim Jagielski:
On Nov 3, 2011, at 2:37
On Fri, Nov 4, 2011 at 4:14 PM, Jim Jagielski wrote:
>
> On Nov 4, 2011, at 4:23 AM, Rüdiger Plüm wrote:
>
>>
>>
>> Am 03.11.2011 20:00, schrieb Jim Jagielski:
>>>
>>> On Nov 3, 2011, at 2:37 PM, Jeff Trawick wrote:
I'm not disputing that there is some undiagnosed situation where
AP
On Nov 4, 2011, at 4:23 AM, Rüdiger Plüm wrote:
>
>
> Am 03.11.2011 20:00, schrieb Jim Jagielski:
>>
>> On Nov 3, 2011, at 2:37 PM, Jeff Trawick wrote:
>>>
>>> I'm not disputing that there is some undiagnosed situation where
>>> APR_ETIMEUP is seen.
>>>
>>> I am looking for confirmation that
Am 03.11.2011 20:36, schrieb Jim Jagielski:
fwiw: I can recreate this at will...
The setup: the jenkins-cli jarfile with Jenkins running in
Winstone/Jetty/Tomcat/JBoss/Doesn'tMatter and Apache frontending
Jenkins with a ProxyPass.
Trying to access Jenkins thru Apache via:
java jenkins-cl
Am 03.11.2011 20:00, schrieb Jim Jagielski:
On Nov 3, 2011, at 2:37 PM, Jeff Trawick wrote:
I'm not disputing that there is some undiagnosed situation where
APR_ETIMEUP is seen.
I am looking for confirmation that APR_ETIMEUP is the expected value.
It's hard to diagnose what the value sho
On Thu, Nov 3, 2011 at 4:09 PM, Jeff Trawick wrote:
> On Thu, Nov 3, 2011 at 3:38 PM, Greg Ames wrote:
> > On Thu, Nov 3, 2011 at 1:06 PM, Jim Jagielski wrote:
> >>
> >> On Nov 3, 2011, at 8:11 AM, Jeff Trawick wrote:
> >> >
>
> > I worked on a bug about a year ago that turned out to be AIX
> i
On Thu, Nov 3, 2011 at 3:38 PM, Greg Ames wrote:
> On Thu, Nov 3, 2011 at 1:06 PM, Jim Jagielski wrote:
>>
>> On Nov 3, 2011, at 8:11 AM, Jeff Trawick wrote:
>> >
>> > Maybe I misunderstood, but I thought Rüdiger's original point was on
>> > track: EAGAIN here is a bug to fix somewhere since EAGA
On Thu, Nov 3, 2011 at 1:06 PM, Jim Jagielski wrote:
>
> On Nov 3, 2011, at 8:11 AM, Jeff Trawick wrote:
> >
> > Maybe I misunderstood, but I thought Rüdiger's original point was on
> > track: EAGAIN here is a bug to fix somewhere since EAGAIN from
> > blocking read is should-not-occur, and this
fwiw: I can recreate this at will...
The setup: the jenkins-cli jarfile with Jenkins running in
Winstone/Jetty/Tomcat/JBoss/Doesn'tMatter and Apache frontending
Jenkins with a ProxyPass.
Trying to access Jenkins thru Apache via:
java jenkins-cli.jar -s http://apache.example.com/
will cause t
On Nov 3, 2011, at 2:37 PM, Jeff Trawick wrote:
>
> I'm not disputing that there is some undiagnosed situation where
> APR_ETIMEUP is seen.
>
> I am looking for confirmation that APR_ETIMEUP is the expected value.
>
It's hard to diagnose what the value should be... all I know
is that what is b
On Thu, Nov 3, 2011 at 2:37 PM, Jeff Trawick wrote:
> On Thu, Nov 3, 2011 at 2:27 PM, Jim Jagielski wrote:
>>
>> On Nov 3, 2011, at 2:07 PM, Jeff Trawick wrote:
>>
>>> On Thu, Nov 3, 2011 at 1:06 PM, Jim Jagielski wrote:
On Nov 3, 2011, at 8:11 AM, Jeff Trawick wrote:
>
> Maybe
On Thu, Nov 3, 2011 at 2:27 PM, Jim Jagielski wrote:
>
> On Nov 3, 2011, at 2:07 PM, Jeff Trawick wrote:
>
>> On Thu, Nov 3, 2011 at 1:06 PM, Jim Jagielski wrote:
>>>
>>> On Nov 3, 2011, at 8:11 AM, Jeff Trawick wrote:
Maybe I misunderstood, but I thought Rüdiger's original point was on
On Nov 3, 2011, at 2:07 PM, Jeff Trawick wrote:
> On Thu, Nov 3, 2011 at 1:06 PM, Jim Jagielski wrote:
>>
>> On Nov 3, 2011, at 8:11 AM, Jeff Trawick wrote:
>>>
>>> Maybe I misunderstood, but I thought Rüdiger's original point was on
>>> track: EAGAIN here is a bug to fix somewhere since EAGAI
On Thu, Nov 3, 2011 at 1:06 PM, Jim Jagielski wrote:
>
> On Nov 3, 2011, at 8:11 AM, Jeff Trawick wrote:
>>
>> Maybe I misunderstood, but I thought Rüdiger's original point was on
>> track: EAGAIN here is a bug to fix somewhere since EAGAIN from
>> blocking read is should-not-occur, and this code
On Nov 3, 2011, at 8:11 AM, Jeff Trawick wrote:
>
> Maybe I misunderstood, but I thought Rüdiger's original point was on
> track: EAGAIN here is a bug to fix somewhere since EAGAIN from
> blocking read is should-not-occur, and this code doesn't need to grow
> another error path.
>
From some re
On Nov 3, 2011, at 7:58 AM, Plüm, Rüdiger, VF-Group wrote:
>>
>> I'm fine with with having a set number of retries with EAGAIN and
>> treating a timeout as an error. If we exhaust the retries, we
>> simply break out of the prefetch loop and continue on, and let
>
> Continue without prefetch in t
On Thu, Nov 3, 2011 at 7:58 AM, "Plüm, Rüdiger, VF-Group"
wrote:
>
>
>> -Original Message-
>> From: Jim Jagielski [mailto:j...@jagunet.com]
>> Sent: Donnerstag, 3. November 2011 12:53
>> To: dev@httpd.apache.org
>> Subject: Re: prefetch p
> -Original Message-
> From: Jim Jagielski [mailto:j...@jagunet.com]
> Sent: Donnerstag, 3. November 2011 12:53
> To: dev@httpd.apache.org
> Subject: Re: prefetch proxy
>
>
> On Nov 2, 2011, at 7:40 AM, Plüm, Rüdiger, VF-Group wrote:
>
> >
> &
On Nov 2, 2011, at 7:40 AM, Plüm, Rüdiger, VF-Group wrote:
>
> I think a timeout should be handled like it is now as failing on
> a slow client is IMHO a desired action by the admin. If he wants to give
> the client more time he should configure a higher timeout.
> For other errors like 'Resourc
> -Original Message-
> From: Jim Jagielski [mailto:j...@jagunet.com]
> Sent: Mittwoch, 2. November 2011 12:22
> To: dev@httpd.apache.org
> Subject: Re: prefetch proxy
>
>
> On Nov 2, 2011, at 5:44 AM, Rüdiger Plüm wrote:
>
> >
> >
> &g
On Nov 2, 2011, at 5:44 AM, Rüdiger Plüm wrote:
>
>
> Am 01.11.2011 21:23, schrieb Jim Jagielski:
>> In mod_proxy_http we have:
>>
>> /* Prefetch MAX_MEM_SPOOL bytes
>> *
>> * This helps us avoid any election of C-L v.s. T-E
>> * request bodies, since we are willing to keep
Am 01.11.2011 21:23, schrieb Jim Jagielski:
In mod_proxy_http we have:
/* Prefetch MAX_MEM_SPOOL bytes
*
* This helps us avoid any election of C-L v.s. T-E
* request bodies, since we are willing to keep in
* memory this much data, in any case. This gives
* u
28 matches
Mail list logo
