Re: MPM-Event, renaming MaxClients, etc.

[Issac Goldstand]

On 21/06/2011 00:30, Roy T. Fielding wrote:
> On Jun 20, 2011, at 12:01 PM, Stefan Fritsch wrote:
>> On Monday 20 June 2011, William A. Rowe Jr. wrote:
>>> On 6/20/2011 9:07 AM, Greg Ames wrote:
 On Sun, Jun 19, 2011 at 8:49 AM, Stefan Fritsch >>> >

 wrote:
Speaking about config options, I think that MaxClients should
be renamed to MaxWorkers, because it limits the number of
worker threads, not the number of clients. As with the
MaxRequestsPerChild -> MaxConnectionsPerChild rename, we
would still accept the old name with a warning. Thoughts?

 +1.  That's more accurate for sure, and more important when you
 loose the 1:1 thread:connection ratio.
>>> Can we call this MaxRequestWorkers, now that we have different
>>> sorts of workers living in the same process?
>> Good point. Committed as r1137744
> That kind of last-minute change is going to kill people trying to
> upgrade from 2.2 to 2.4 with a shared config.  We should make
> MaxRequestWorkers an alias for MaxClients in a released 2.2.x
>
> Roy
+1

Re: MPM-Event, renaming MaxClients, etc.

[Daniel Ruggeri]

On 6/20/2011 6:22 PM, Roy T. Fielding wrote:
> My point wasn't the warning, actually, but rather the fact that a config
> that uses MaxRequestWorkers (instead of MaxClients) will abort an instance
> of httpd 2.2.x.  Hence, a person upgrading to 2.4.x will get tripped up
> if they try to do so incrementally with shared config files across
> many web servers, unless they happen to notice that this change is
> merely cosmetic and they keep MaxClients instead.
>
> For a trivial improvement like this, we should make it easier on admins
> by backporting the alias to 2.2.x (even if we do not use it on 2.2.x).
>
> Roy
+1  Sorry, I didn't catch that - good point.

-- 
--
Daniel Ruggeri

Re: MPM-Event, renaming MaxClients, etc.

[William A. Rowe Jr.]

On 6/20/2011 6:22 PM, Roy T. Fielding wrote:
> 
> For a trivial improvement like this, we should make it easier on admins
> by backporting the alias to 2.2.x (even if we do not use it on 2.2.x).

+1

Re: MPM-Event, renaming MaxClients, etc.

[Roy T. Fielding]

On Jun 20, 2011, at 2:48 PM, William A. Rowe Jr. wrote:
> On 6/20/2011 4:36 PM, Stefan Fritsch wrote:
>> On Monday 20 June 2011, Roy T. Fielding wrote:
>>> On Jun 20, 2011, at 12:01 PM, Stefan Fritsch wrote:
 On Monday 20 June 2011, William A. Rowe Jr. wrote:
> On 6/20/2011 9:07 AM, Greg Ames wrote:
>> On Sun, Jun 19, 2011 at 8:49 AM, Stefan Fritsch > >
>> 
>> wrote:
>>   Speaking about config options, I think that MaxClients
>>   should be renamed to MaxWorkers, because it limits the
>>   number of worker threads, not the number of clients. As
>>   with the MaxRequestsPerChild -> MaxConnectionsPerChild
>>   rename, we would still accept the old name with a warning.
>>   Thoughts?
>> 
>> +1.  That's more accurate for sure, and more important when you
>> loose the 1:1 thread:connection ratio.
> 
> Can we call this MaxRequestWorkers, now that we have different
> sorts of workers living in the same process?
 
 Good point. Committed as r1137744
>>> 
>>> That kind of last-minute change is going to kill people trying to
>>> upgrade from 2.2 to 2.4 with a shared config.  We should make
>>> MaxRequestWorkers an alias for MaxClients in a released 2.2.x
>> 
>> I think you missed that MaxClients still works in 2.4 (albeit with a 
>> warning on startup). So I don't think it's such a big deal.
> 
> Perhaps we should lower the severity from warning to info?  Not every
> admin needs constant reminders while they are running 2.2 and 2.4 from
> a single config.

My point wasn't the warning, actually, but rather the fact that a config
that uses MaxRequestWorkers (instead of MaxClients) will abort an instance
of httpd 2.2.x.  Hence, a person upgrading to 2.4.x will get tripped up
if they try to do so incrementally with shared config files across
many web servers, unless they happen to notice that this change is
merely cosmetic and they keep MaxClients instead.

For a trivial improvement like this, we should make it easier on admins
by backporting the alias to 2.2.x (even if we do not use it on 2.2.x).

Roy

Re: MPM-Event, renaming MaxClients, etc.

[Stefan Fritsch]

On Tuesday 21 June 2011, Daniel Ruggeri wrote:
> On 6/20/2011 4:48 PM, William A. Rowe Jr. wrote:
> > On 6/20/2011 4:36 PM, Stefan Fritsch wrote:
> >> On Monday 20 June 2011, Roy T. Fielding wrote:
> >>> On Jun 20, 2011, at 12:01 PM, Stefan Fritsch wrote:
>  
> >>> 
> >>> That kind of last-minute change is going to kill people trying
> >>> to upgrade from 2.2 to 2.4 with a shared config.  We should
> >>> make MaxRequestWorkers an alias for MaxClients in a released
> >>> 2.2.x
> >> 
> >> I think you missed that MaxClients still works in 2.4 (albeit
> >> with a warning on startup). So I don't think it's such a big
> >> deal.
> > 
> > Perhaps we should lower the severity from warning to info?  Not
> > every admin needs constant reminders while they are running 2.2
> > and 2.4 from a single config.
> 
> +1... warning seems a bit dire for the circumstances.

Sounds reasonable. r1137813

Re: MPM-Event, renaming MaxClients, etc.

[Daniel Ruggeri]

On 6/20/2011 4:48 PM, William A. Rowe Jr. wrote:
> On 6/20/2011 4:36 PM, Stefan Fritsch wrote:
>> On Monday 20 June 2011, Roy T. Fielding wrote:
>>> On Jun 20, 2011, at 12:01 PM, Stefan Fritsch wrote:
 
>>> That kind of last-minute change is going to kill people trying to
>>> upgrade from 2.2 to 2.4 with a shared config.  We should make
>>> MaxRequestWorkers an alias for MaxClients in a released 2.2.x
>> I think you missed that MaxClients still works in 2.4 (albeit with a 
>> warning on startup). So I don't think it's such a big deal.
> Perhaps we should lower the severity from warning to info?  Not every
> admin needs constant reminders while they are running 2.2 and 2.4 from
> a single config.
>
+1... warning seems a bit dire for the circumstances.

-- 
--
Daniel Ruggeri

Re: Module External Configuration

[Nick Kew]

On Mon, 20 Jun 2011 16:10:12 -0400
Mike Meyer  wrote:


>   I assume that this is because a new process was spawned to
> > handle a new request and the updated memory didn't get carried over (even
> > though the pointer address didn't change...)

A new process may be spawned from time to time (though not directly
to handle a new request unless you have a very non-standard MPM).
You could check config data in a child_init hook.

However, if you have this problem, it's probably not your only one.
The data reverting suggests that your module's config may be held
on the server/config pool.  If that's being updated (and if the
updates involve any allocation at all) it's a memory leak.  Your
module should create its own config pool at child_init.  Then it
can read its own config data immediately, and - crucially -
whenever it re-reads the data it can first clean that pool to
reclaim memory.

> Put the configuration data into shared memory. Create and load the
> shared memory in the post config hook. Map the shared memory and
> potentially reload it during the child init hook. You'll need to use
> appropriate locking if you decide to reload it. Details on the locking
> will depend on the data structure details.

If you use shared memory, note that 2.3/2.4 have much better support for
it than earlier versions, with mod_socache and mod_slotmem.

However, this may not be the best thing to do.  You need to weigh up the
cost of maintaining a per-process copy of the config data against that
of using shared memory.  Both are valid solutions.

Also, do you want the overhead of a stat() every request to see if
anything has changed, or could it work on a time basis, so it only
performs a stat() if a certain time has elapsed since the last time?

-- 
Nick Kew

Available for work, contract or permanent.
http://www.webthing.com/~nick/cv.html

Re: Module External Configuration

[Sorin Manolache]

On Mon, Jun 20, 2011 at 22:46, Jason Funk  wrote:
> I have moved my configuration over to shared memory (following
> mod_shm_counter as an example) and it conceptually seems to be working. I am
> storing a struct in the memory and members that share it's memory (such as
> the last mod time of the configuration file) persist over multiple children.
> However, when I am loading the configuration file I have to allocate
> additional memory. This apparently doesn't get stored in the same shared
> memory as it isn't sticking around. How do I dynamically allocate new memory
> to the struct that lives in shared memory?

Try C++ and boost::interprocess::managed_shared_memory and
boost::interprocess::allocator.

Sorin

>
> Jason
>
> On Mon, Jun 20, 2011 at 3:29 PM, Neil McKee  wrote:
>
>> In the mod-sflow implementation I have one thread responsible for reading
>> in new configuration as it changes and writing it to a shared-memory area
>> where the worker-processes/threads can pick it up whenever it changes.   I
>> don't know if that is the best way or not,  but it's one data point for you.
>>   Source code is here:
>>
>> http://mod-sflow.googlecode.com
>>
>> Neil
>>
>>
>> On Jun 20, 2011, at 11:39 AM, Jason Funk wrote:
>>
>> > Hello,
>> >
>> > The module that I am writing has an external configuration file that it
>> > parses and loads into configuration when the server loads. Before every
>> > request it checks to see if the configuration file has been updated and
>> if
>> > it has it reloads the configuration. The configuration should be shared
>> over
>> > the entire server. The problem I am running into is that after the
>> > configuration file is updated the new configuration gets reloaded and
>> stored
>> > in memory but after a little while, the configuration reverts back to
>> it's
>> > previous version. I assume that this is because a new process was spawned
>> to
>> > handle a new request and the updated memory didn't get carried over (even
>> > though the pointer address didn't change...)
>> >
>> > My question is this: What mechanism should I be using in order to
>> > store persistent, mutable, configuration data that is shared between
>> every
>> > child process?
>> >
>> >
>> > Jason
>>
>>
>

Re: MPM-Event, renaming MaxClients, etc.

[William A. Rowe Jr.]

On 6/20/2011 4:36 PM, Stefan Fritsch wrote:
> On Monday 20 June 2011, Roy T. Fielding wrote:
>> On Jun 20, 2011, at 12:01 PM, Stefan Fritsch wrote:
>>> On Monday 20 June 2011, William A. Rowe Jr. wrote:
 On 6/20/2011 9:07 AM, Greg Ames wrote:
> On Sun, Jun 19, 2011 at 8:49 AM, Stefan Fritsch  >
>
> wrote:
>Speaking about config options, I think that MaxClients
>should be renamed to MaxWorkers, because it limits the
>number of worker threads, not the number of clients. As
>with the MaxRequestsPerChild -> MaxConnectionsPerChild
>rename, we would still accept the old name with a warning.
>Thoughts?
>
> +1.  That's more accurate for sure, and more important when you
> loose the 1:1 thread:connection ratio.

 Can we call this MaxRequestWorkers, now that we have different
 sorts of workers living in the same process?
>>>
>>> Good point. Committed as r1137744
>>
>> That kind of last-minute change is going to kill people trying to
>> upgrade from 2.2 to 2.4 with a shared config.  We should make
>> MaxRequestWorkers an alias for MaxClients in a released 2.2.x
> 
> I think you missed that MaxClients still works in 2.4 (albeit with a 
> warning on startup). So I don't think it's such a big deal.

Perhaps we should lower the severity from warning to info?  Not every
admin needs constant reminders while they are running 2.2 and 2.4 from
a single config.

Re: MPM-Event, renaming MaxClients, etc.

[Stefan Fritsch]

On Monday 20 June 2011, Roy T. Fielding wrote:
> On Jun 20, 2011, at 12:01 PM, Stefan Fritsch wrote:
> > On Monday 20 June 2011, William A. Rowe Jr. wrote:
> >> On 6/20/2011 9:07 AM, Greg Ames wrote:
> >>> On Sun, Jun 19, 2011 at 8:49 AM, Stefan Fritsch  >>> >
> >>> 
> >>> wrote:
> >>>Speaking about config options, I think that MaxClients
> >>>should be renamed to MaxWorkers, because it limits the
> >>>number of worker threads, not the number of clients. As
> >>>with the MaxRequestsPerChild -> MaxConnectionsPerChild
> >>>rename, we would still accept the old name with a warning.
> >>>Thoughts?
> >>> 
> >>> +1.  That's more accurate for sure, and more important when you
> >>> loose the 1:1 thread:connection ratio.
> >> 
> >> Can we call this MaxRequestWorkers, now that we have different
> >> sorts of workers living in the same process?
> > 
> > Good point. Committed as r1137744
> 
> That kind of last-minute change is going to kill people trying to
> upgrade from 2.2 to 2.4 with a shared config.  We should make
> MaxRequestWorkers an alias for MaxClients in a released 2.2.x

I think you missed that MaxClients still works in 2.4 (albeit with a 
warning on startup). So I don't think it's such a big deal.

Re: MPM-Event, renaming MaxClients, etc.

[Roy T. Fielding]

On Jun 20, 2011, at 12:01 PM, Stefan Fritsch wrote:
> On Monday 20 June 2011, William A. Rowe Jr. wrote:
>> On 6/20/2011 9:07 AM, Greg Ames wrote:
>>> On Sun, Jun 19, 2011 at 8:49 AM, Stefan Fritsch >> >
>>> 
>>> wrote:
>>>Speaking about config options, I think that MaxClients should
>>>be renamed to MaxWorkers, because it limits the number of
>>>worker threads, not the number of clients. As with the
>>>MaxRequestsPerChild -> MaxConnectionsPerChild rename, we
>>>would still accept the old name with a warning. Thoughts?
>>> 
>>> +1.  That's more accurate for sure, and more important when you
>>> loose the 1:1 thread:connection ratio.
>> 
>> Can we call this MaxRequestWorkers, now that we have different
>> sorts of workers living in the same process?
> 
> Good point. Committed as r1137744

That kind of last-minute change is going to kill people trying to
upgrade from 2.2 to 2.4 with a shared config.  We should make
MaxRequestWorkers an alias for MaxClients in a released 2.2.x

Roy

Re: Module External Configuration

[Ben Noordhuis]

On Mon, Jun 20, 2011 at 22:46, Jason Funk  wrote:
> I have moved my configuration over to shared memory (following
> mod_shm_counter as an example) and it conceptually seems to be working. I am
> storing a struct in the memory and members that share it's memory (such as
> the last mod time of the configuration file) persist over multiple children.
> However, when I am loading the configuration file I have to allocate
> additional memory. This apparently doesn't get stored in the same shared
> memory as it isn't sticking around. How do I dynamically allocate new memory
> to the struct that lives in shared memory?

You cannot (portably), you'll have to reserve the extra space when you
the allocate the shared memory.

Re: Module External Configuration

[Jason Funk]

I have moved my configuration over to shared memory (following
mod_shm_counter as an example) and it conceptually seems to be working. I am
storing a struct in the memory and members that share it's memory (such as
the last mod time of the configuration file) persist over multiple children.
However, when I am loading the configuration file I have to allocate
additional memory. This apparently doesn't get stored in the same shared
memory as it isn't sticking around. How do I dynamically allocate new memory
to the struct that lives in shared memory?

Jason

On Mon, Jun 20, 2011 at 3:29 PM, Neil McKee  wrote:

> In the mod-sflow implementation I have one thread responsible for reading
> in new configuration as it changes and writing it to a shared-memory area
> where the worker-processes/threads can pick it up whenever it changes.   I
> don't know if that is the best way or not,  but it's one data point for you.
>   Source code is here:
>
> http://mod-sflow.googlecode.com
>
> Neil
>
>
> On Jun 20, 2011, at 11:39 AM, Jason Funk wrote:
>
> > Hello,
> >
> > The module that I am writing has an external configuration file that it
> > parses and loads into configuration when the server loads. Before every
> > request it checks to see if the configuration file has been updated and
> if
> > it has it reloads the configuration. The configuration should be shared
> over
> > the entire server. The problem I am running into is that after the
> > configuration file is updated the new configuration gets reloaded and
> stored
> > in memory but after a little while, the configuration reverts back to
> it's
> > previous version. I assume that this is because a new process was spawned
> to
> > handle a new request and the updated memory didn't get carried over (even
> > though the pointer address didn't change...)
> >
> > My question is this: What mechanism should I be using in order to
> > store persistent, mutable, configuration data that is shared between
> every
> > child process?
> >
> >
> > Jason
>
>

Re: Module External Configuration

[Neil McKee]

In the mod-sflow implementation I have one thread responsible for reading in 
new configuration as it changes and writing it to a shared-memory area where 
the worker-processes/threads can pick it up whenever it changes.   I don't know 
if that is the best way or not,  but it's one data point for you.   Source code 
is here:

http://mod-sflow.googlecode.com

Neil


On Jun 20, 2011, at 11:39 AM, Jason Funk wrote:

> Hello,
> 
> The module that I am writing has an external configuration file that it
> parses and loads into configuration when the server loads. Before every
> request it checks to see if the configuration file has been updated and if
> it has it reloads the configuration. The configuration should be shared over
> the entire server. The problem I am running into is that after the
> configuration file is updated the new configuration gets reloaded and stored
> in memory but after a little while, the configuration reverts back to it's
> previous version. I assume that this is because a new process was spawned to
> handle a new request and the updated memory didn't get carried over (even
> though the pointer address didn't change...)
> 
> My question is this: What mechanism should I be using in order to
> store persistent, mutable, configuration data that is shared between every
> child process?
> 
> 
> Jason

Re: Module External Configuration

[Mike Meyer]

On Mon, 20 Jun 2011 13:39:48 -0500
Jason Funk  wrote:

> Hello,
> 
> The module that I am writing has an external configuration file that it
> parses and loads into configuration when the server loads. Before every
> request it checks to see if the configuration file has been updated and if
> it has it reloads the configuration. The configuration should be shared over
> the entire server. The problem I am running into is that after the
> configuration file is updated the new configuration gets reloaded and stored
> in memory but after a little while, the configuration reverts back to it's
> previous version. I assume that this is because a new process was spawned to
> handle a new request and the updated memory didn't get carried over (even
> though the pointer address didn't change...)
> 
> My question is this: What mechanism should I be using in order to
> store persistent, mutable, configuration data that is shared between every
> child process?

Put the configuration data into shared memory. Create and load the
shared memory in the post config hook. Map the shared memory and
potentially reload it during the child init hook. You'll need to use
appropriate locking if you decide to reload it. Details on the locking
will depend on the data structure details.

 http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

REMINDER: Participation Requested: Survey about Open-Source Software Development

[Jeffrey Carver]

Hi,

Apologies for any inconvenience and thank you to those who have already
completed the survey. We will keep the survey open for another couple of
weeks. But, we do hope you will consider responding to the email request
below (sent 2 weeks ago).

Thanks,

Dr. Jeffrey Carver
Assistant Professor
University of Alabama
(v) 205-348-9829  (f) 205-348-0219
http://www.cs.ua.edu/~carver

-Original Message-
From: Jeffrey Carver [mailto:opensourcesur...@cs.ua.edu] 
Sent: Monday, June 13, 2011 11:24 AM
To: 'dev@httpd.apache.org'
Subject: Participation Requested: Survey about Open-Source Software
Development

Hi,

Drs. Jeffrey Carver, Rosanna Guadagno, Debra McCallum, and Mr. Amiangshu
Bosu,  University of Alabama, and Dr. Lorin Hochstein, University of
Southern California, are conducting a survey of open-source software
developers. This survey seeks to understand how developers on distributed,
virtual teams, like open-source projects, interact with each other to
accomplish their tasks. You must be at least 19 years of age to complete the
survey. The survey should take approximately 15 minutes to complete.

If you are actively participating as a developer, please consider completing
our survey.
 
Here is the link to the survey:   http://goo.gl/HQnux

We apologize for inconvenience and if you receive multiple copies of this
email. This survey has been approved by The University of Alabama IRB board.

Thanks,

Dr. Jeffrey Carver
Assistant Professor
University of Alabama
(v) 205-348-9829  (f) 205-348-0219
http://www.cs.ua.edu/~carver

Re: MPM-Event, renaming MaxClients, etc.

[Stefan Fritsch]

On Monday 20 June 2011, William A. Rowe Jr. wrote:
> On 6/20/2011 9:07 AM, Greg Ames wrote:
> > On Sun, Jun 19, 2011 at 8:49 AM, Stefan Fritsch  > >
> > 
> > wrote:
> > Speaking about config options, I think that MaxClients should
> > be renamed to MaxWorkers, because it limits the number of
> > worker threads, not the number of clients. As with the
> > MaxRequestsPerChild -> MaxConnectionsPerChild rename, we
> > would still accept the old name with a warning. Thoughts?
> > 
> > +1.  That's more accurate for sure, and more important when you
> > loose the 1:1 thread:connection ratio.
> 
> Can we call this MaxRequestWorkers, now that we have different
> sorts of workers living in the same process?

Good point. Committed as r1137744

Module External Configuration

[Jason Funk]

Hello,

The module that I am writing has an external configuration file that it
parses and loads into configuration when the server loads. Before every
request it checks to see if the configuration file has been updated and if
it has it reloads the configuration. The configuration should be shared over
the entire server. The problem I am running into is that after the
configuration file is updated the new configuration gets reloaded and stored
in memory but after a little while, the configuration reverts back to it's
previous version. I assume that this is because a new process was spawned to
handle a new request and the updated memory didn't get carried over (even
though the pointer address didn't change...)

My question is this: What mechanism should I be using in order to
store persistent, mutable, configuration data that is shared between every
child process?


Jason

Re: Time for httpd 2.3.13...? And 2.4.0??

[Jim Jagielski]

On Jun 19, 2011, at 1:55 AM, Rainer Jung wrote:

> On 18.06.2011 14:44, Stefan Fritsch wrote:
>> On Friday 17 June 2011, William A. Rowe Jr. wrote:
>>> On 6/17/2011 6:39 AM, Jim Jagielski wrote:
 Are we ready for the next beta release???
 
 And Maybe Even The Next Release being GA??
>>> 
>>> 2.3.13 soon, I'll fix the mod_ldap load ordering quirk on Sunday
>>> and just do a bit more validation with apr trunk.
>> 
>> I am currently working on limiting the parallel connections per 
>> process on MPM event (see STATUS). I would really like to have this in 
>> 2.3.13, but I hope I will be able to finish it until tomorrow.
>> 
>>> The Next Release?  I'm not seeing enough activity on users@ and not
>>> even seeing current ASF infra updated enough to justify that ;-)
>>> But if 2.2.13 proves rock solid, maybe the subsequent release?
>> 
>> +1 to 2.3.13 as beta. Then hopefully the next release can be GA.
> 
> Agreed.
> 

Cool...

Re: MPM-Event, renaming MaxClients, etc.

[William A. Rowe Jr.]

On 6/20/2011 9:07 AM, Greg Ames wrote:
> 
> On Sun, Jun 19, 2011 at 8:49 AM, Stefan Fritsch  >
> wrote:
> 
> Speaking about config options, I think that MaxClients should be
> renamed to MaxWorkers, because it limits the number of worker threads,
> not the number of clients. As with the MaxRequestsPerChild ->
> MaxConnectionsPerChild rename, we would still accept the old name with
> a warning. Thoughts?
> 
> +1.  That's more accurate for sure, and more important when you loose the 1:1
> thread:connection ratio.

Can we call this MaxRequestWorkers, now that we have different sorts of workers
living in the same process?

Re: svn commit: r916377 - in /httpd/httpd/trunk: CHANGES docs/manual/programs/rotatelogs.xml support/rotatelogs.c

[Graham Leggett]

On 20 Jun 2011, at 12:58 PM, Plüm, Rüdiger, VF-Group wrote:


more general
-p mode just added - is it worth keeping?


I think it is worth keeping for those people that only need the link.
Creating a post rotation script that does this seems to be a little
bit of overkill in this case.


+1.

Regards,
Graham
--

Re: MPM-Event, renaming MaxClients, etc.

[Greg Ames]

On Sun, Jun 19, 2011 at 8:49 AM, Stefan Fritsch  wrote:
>
>
> Speaking about config options, I think that MaxClients should be
> renamed to MaxWorkers, because it limits the number of worker threads,
> not the number of clients. As with the MaxRequestsPerChild ->
> MaxConnectionsPerChild rename, we would still accept the old name with
> a warning. Thoughts?


+1.  That's more accurate for sure, and more important when you loose the
1:1 thread:connection ratio.

Greg

Dead assignment detected from commit 1137358

[Chris Wilson]

Hi,

We are using Sentry (a C/C++ static analysis tool) to analyze
httpd on a nightly basis. Sentry found that a dead assignment
was recently introduced in the commit r1137358.

This was in event.c:process_socket. The variable pt
was previously used lower in the function, but after the patch
above was applied it is now only used in a local if scope.

This is basically a code clean up patch.

Thanks,
Chris

-- 
Chris Wilson
http://vigilantsw.com/
Vigilant Software, LLC
Index: server/mpm/event/event.c
===
--- server/mpm/event/event.c	(revision 1137629)
+++ server/mpm/event/event.c	(working copy)
@@ -787,7 +787,6 @@
   int my_thread_num)
 {
 conn_rec *c;
-listener_poll_type *pt;
 long conn_id = ID_FROM_CHILD_THREAD(my_child_num, my_thread_num);
 int rc;
 ap_sb_handle_t *sbh;
@@ -795,6 +794,7 @@
 ap_create_sb_handle(&sbh, p, my_child_num, my_thread_num);
 
 if (cs == NULL) {   /* This is a new connection */
+listener_poll_type *pt;
 
 cs = apr_pcalloc(p, sizeof(conn_state_t));
 
@@ -845,7 +845,6 @@
 else {
 c = cs->c;
 c->sbh = sbh;
-pt = cs->pfd.client_data;
 c->current_thread = thd;
 }
 

RE: svn commit: r916377 - in /httpd/httpd/trunk: CHANGES docs/manual/programs/rotatelogs.xml support/rotatelogs.c

[Plüm, Rüdiger, VF-Group]

 

> -Original Message-
> From: Joe Orton 
> Sent: Montag, 20. Juni 2011 12:44
> To: dev@httpd.apache.org
> Subject: Re: svn commit: r916377 - in /httpd/httpd/trunk: 
> CHANGES docs/manual/programs/rotatelogs.xml support/rotatelogs.c
> 
> Dredging up an change from last year:
> 
> On Thu, Feb 25, 2010 at 06:00:43PM -, poir...@apache.org wrote:
> > Author: poirier
> > Date: Thu Feb 25 18:00:42 2010
> > New Revision: 916377
> > 
> > URL: http://svn.apache.org/viewvc?rev=916377&view=rev
> > Log:
> > Add -L option to create a hard link to the current log file.  
> ...
> > @@ -351,6 +354,20 @@
> >  status->pfile_prev = NULL;
> >  }
> >  status->nMessCount = 0;
> > +if (config->linkfile) {
> > +apr_file_remove(config->linkfile, status->pfile);
> > +if (config->verbose) {
> > +fprintf(stderr,"Linking %s to %s\n", 
> status->filename, config->linkfile);
> > +}
> > +rv = apr_file_link(status->filename, config->linkfile);
> 
> This snippet gets invoked even in the case where opening a 
> new log file 
> fails, and the old one is truncated and re-used; it will then 
> fail and 
> break the link, I think.  -L is kind of redundant with the 

Why? Because status->filename is not pointing to the old filename?

> more general 
> -p mode just added - is it worth keeping?

I think it is worth keeping for those people that only need the link.
Creating a post rotation script that does this seems to be a little
bit of overkill in this case.

Regards

Rüdiger

Re: svn commit: r916377 - in /httpd/httpd/trunk: CHANGES docs/manual/programs/rotatelogs.xml support/rotatelogs.c

[Joe Orton]

Dredging up an change from last year:

On Thu, Feb 25, 2010 at 06:00:43PM -, poir...@apache.org wrote:
> Author: poirier
> Date: Thu Feb 25 18:00:42 2010
> New Revision: 916377
> 
> URL: http://svn.apache.org/viewvc?rev=916377&view=rev
> Log:
> Add -L option to create a hard link to the current log file.  
...
> @@ -351,6 +354,20 @@
>  status->pfile_prev = NULL;
>  }
>  status->nMessCount = 0;
> +if (config->linkfile) {
> +apr_file_remove(config->linkfile, status->pfile);
> +if (config->verbose) {
> +fprintf(stderr,"Linking %s to %s\n", status->filename, 
> config->linkfile);
> +}
> +rv = apr_file_link(status->filename, config->linkfile);

This snippet gets invoked even in the case where opening a new log file 
fails, and the old one is truncated and re-used; it will then fail and 
break the link, I think.  -L is kind of redundant with the more general 
-p mode just added - is it worth keeping?

http://svn.apache.org/viewvc?view=revision&revision=1137590

Regards, Joe