Mailing List Archive: Apache: Dev

Re: svn commit: r883712 - /httpd/httpd/trunk/docs/manual/mod/core.xml

Index | Next | Previous | View Threaded

trawick at gmail

Nov 24, 2009, 6:59 AM

Post #1 of 7 (754 views)
Permalink

Re: svn commit: r883712 - /httpd/httpd/trunk/docs/manual/mod/core.xml

On Tue, Nov 24, 2009 at 9:54 AM, <trawick [at] apache> wrote:
> Author: trawick
> Date: Tue Nov 24 14:54:03 2009
> New Revision: 883712
>
> URL: http://svn.apache.org/viewvc?rev=883712&view=rev
> Log:
> document the new Mutex directive, pulling in any existing special considerations described in the
> documentation of the old LockFile, AcceptMutex, RewriteLock, and SSLMutex directives

I'll axe the old directive documentation and update any other affected
documentation once wrowe's concern about cross-node lock files is
resolved (barring any other concerns I'm yet to be informed of ;) ).

wrowe at rowe-clan

Nov 24, 2009, 8:53 AM

Post #2 of 7 (709 views)
Permalink

Re: svn commit: r883712 - /httpd/httpd/trunk/docs/manual/mod/core.xml [In reply to]

Jeff Trawick wrote:
> On Tue, Nov 24, 2009 at 9:54 AM, <trawick [at] apache> wrote:
>> Author: trawick
>> Date: Tue Nov 24 14:54:03 2009
>> New Revision: 883712
>>
>> URL: http://svn.apache.org/viewvc?rev=883712&view=rev
>> Log:
>> document the new Mutex directive, pulling in any existing special considerations described in the
>> documentation of the old LockFile, AcceptMutex, RewriteLock, and SSLMutex directives
>
> I'll axe the old directive documentation and update any other affected
> documentation once wrowe's concern about cross-node lock files is
> resolved (barring any other concerns I'm yet to be informed of ;) ).

It sounds like this is resolved, and was nothing more than the confusion
I introduced when I didn't update the docs to match the code revision.
Sorry about that - I presume your patch will simply normalize all this
documentation, and we can call it a day.

Looking forward to the directive docs, happy to review!

trawick at gmail

Nov 24, 2009, 9:29 AM

Post #3 of 7 (714 views)
Permalink

Re: svn commit: r883712 - /httpd/httpd/trunk/docs/manual/mod/core.xml [In reply to]

On Tue, Nov 24, 2009 at 11:53 AM, William A. Rowe Jr.
<wrowe [at] rowe-clan> wrote:
> Jeff Trawick wrote:
>> On Tue, Nov 24, 2009 at 9:54 AM, <trawick [at] apache> wrote:
>>> Author: trawick
>>> Date: Tue Nov 24 14:54:03 2009
>>> New Revision: 883712
>>>
>>> URL: http://svn.apache.org/viewvc?rev=883712&view=rev
>>> Log:
>>> document the new Mutex directive, pulling in any existing special considerations described in the
>>> documentation of the old LockFile, AcceptMutex, RewriteLock, and SSLMutex directives
>>
>> I'll axe the old directive documentation and update any other affected
>> documentation once wrowe's concern about cross-node lock files is
>> resolved (barring any other concerns I'm yet to be informed of ;) ).
>
> It sounds like this is resolved,

I'm not so sure ;)

> and was nothing more than the confusion
> I introduced when I didn't update the docs to match the code revision.

It is true that your requirement (as I understand it) for the SSL
session cache mutex -- that the complete name be fully
predictable/configurable and not contain the pid -- was not reflected
in the docs.

But the Mutex directive and ap_mutex_*() APIs don't currently support
that requirement, always appending a pid to the name of the lock file.

What about an optional third argument to Mutex to indicate that the
pid should be omitted?

Mutex default sysvsem
Mutex ssl-cache file:/mnt/sesscachedir OmitPid
etc.

In the ssl-cache example, the name of the mutex will be simply
/mnt/sesscachedir/ssl-cache

Does that meet the special SSLMutex requirement?

wrowe at rowe-clan

Nov 24, 2009, 10:58 AM

Post #4 of 7 (702 views)
Permalink

Re: svn commit: r883712 - /httpd/httpd/trunk/docs/manual/mod/core.xml [In reply to]

Jeff Trawick wrote:
>
> What about an optional third argument to Mutex to indicate that the
> pid should be omitted?
>
> Mutex default sysvsem
> Mutex ssl-cache file:/mnt/sesscachedir OmitPid
> etc.

That seems sensible, but I'm left wondering how many different naming
conventions we can fit on one directive line. Perhaps bOmitPID instead ;-)
This really becomes harder to follow than the existing multiple-syntaxes.

Is there any reason not to name these mutexes in MixedCase?

Is there any reason we can't invert the arg order, so that we have

Mutex mutextype:name Resource [Resource ...] [OmitPid]

Of course, default could be assumed here. So the above becomes

Mutex SysVSem
Mutex file:/mnt/sesscachedir SSLSessionCache OmitPid

(note the Resource tag can be the actual directive being mutexed, instead
of an alt-name).

Thoughts?

> In the ssl-cache example, the name of the mutex will be simply
> /mnt/sesscachedir/ssl-cache
>
> Does that meet the special SSLMutex requirement?

Well, it's not strictly SSLMutex, but any other shared-resource that
requires cross process/cross machine mutexing.

trawick at gmail

Nov 24, 2009, 12:00 PM

Post #5 of 7 (700 views)
Permalink

Re: svn commit: r883712 - /httpd/httpd/trunk/docs/manual/mod/core.xml [In reply to]

On Tue, Nov 24, 2009 at 1:58 PM, William A. Rowe Jr.
<wrowe [at] rowe-clan> wrote:
> Jeff Trawick wrote:
>>
>> What about an optional third argument to Mutex to indicate that the
>> pid should be omitted?
>>
>> Mutex default sysvsem
>> Mutex ssl-cache file:/mnt/sesscachedir OmitPid
>> etc.
>
> That seems sensible, but I'm left wondering how many different naming
> conventions we can fit on one directive line. Perhaps bOmitPID instead ;-)
> This really becomes harder to follow than the existing multiple-syntaxes.
>
> Is there any reason not to name these mutexes in MixedCase?

I like having the mutex type name as of the filename, and mixed case
filenames are unexpected. Beyond that, MixedCase and the "." before
the pid suffix don't totally resolve readability. Modules like
mod_watchdog with multi-instance mutexes provide an instance string
which gets inserted as "-" string prior to the . pid suffix.

If the watchdog names are heartbeat and dialup (wild guess; I didn't
look closely or try to configure the thing), the files would be

logs/watchdog-callback-heartbeat.1359
logs/watchdog-callback-dialup.1359

(These are both instances of the "watchdog-callback" type, which is
what would be specified on the Mutex directive.)

> Is there any reason we can't invert the arg order, so that we have
>
> Mutex mutextype:name Resource [Resource ...] [OmitPid]

Maybe it would be clearer if the optional OmitPid came before the list
of mutexes?

>
> Of course, default could be assumed here. So the above becomes
>
> Mutex SysVSem
> Mutex file:/mnt/sesscachedir SSLSessionCache OmitPid
>
> (note the Resource tag can be the actual directive being mutexed, instead
> of an alt-name).
>
> Thoughts?

I'm fine with putting the mechanism:dir first followed by a list of
mutex type names. I'm not sure about where to put the OmitPid though.
I guess you get used to either after a while.

(Joe suggested "Mutex name1,name2,name3 mechanism:dir"; I didn't get
around to splitting up the first arg to implement that.)

>> In the ssl-cache example, the name of the mutex will be simply
>> /mnt/sesscachedir/ssl-cache
>>
>> Does that meet the special SSLMutex requirement?
>
> Well, it's not strictly SSLMutex,

understood that its a general capability

> but any other shared-resource that
> requires cross process/cross machine mutexing.

The SSL session cache mutex is the only use case we have now.

At any rate, I take that as a "yes" answer ;) (user somehow says
omit-the-pid on the Mutex directive, case closed)

trawick at gmail

Nov 24, 2009, 1:45 PM

Post #6 of 7 (710 views)
Permalink

Re: svn commit: r883712 - /httpd/httpd/trunk/docs/manual/mod/core.xml [In reply to]

On Tue, Nov 24, 2009 at 3:00 PM, Jeff Trawick <trawick [at] gmail> wrote:
> On Tue, Nov 24, 2009 at 1:58 PM, William A. Rowe Jr.
> <wrowe [at] rowe-clan> wrote:
>> Jeff Trawick wrote:
>>>
>>> What about an optional third argument to Mutex to indicate that the
>>> pid should be omitted?
>>>
>>> Mutex default sysvsem
>>> Mutex ssl-cache file:/mnt/sesscachedir OmitPid
>>> etc.
>>
>> That seems sensible, but I'm left wondering how many different naming
>> conventions we can fit on one directive line. Perhaps bOmitPID instead ;-)
>> This really becomes harder to follow than the existing multiple-syntaxes.
>>
>> Is there any reason not to name these mutexes in MixedCase?
>
> I like having the mutex type name as of the filename, and mixed case
> filenames are unexpected. Beyond that, MixedCase and the "." before
> the pid suffix don't totally resolve readability. Modules like
> mod_watchdog with multi-instance mutexes provide an instance string
> which gets inserted as "-" string prior to the . pid suffix.
>
> If the watchdog names are heartbeat and dialup (wild guess; I didn't
> look closely or try to configure the thing), the files would be
>
> logs/watchdog-callback-heartbeat.1359
> logs/watchdog-callback-dialup.1359
>
> (These are both instances of the "watchdog-callback" type, which is
> what would be specified on the Mutex directive.)
>
>> Is there any reason we can't invert the arg order, so that we have
>>
>> Mutex mutextype:name Resource [Resource ...] [OmitPid]
>
> Maybe it would be clearer if the optional OmitPid came before the list
> of mutexes?
>
>>
>> Of course, default could be assumed here. So the above becomes
>>
>> Mutex SysVSem
>> Mutex file:/mnt/sesscachedir SSLSessionCache OmitPid
>>
>> (note the Resource tag can be the actual directive being mutexed, instead
>> of an alt-name).
>>
>> Thoughts?
>
> I'm fine with putting the mechanism:dir first followed by a list of
> mutex type names. I'm not sure about where to put the OmitPid though.
> I guess you get used to either after a while.
>
> (Joe suggested "Mutex name1,name2,name3 mechanism:dir"; I didn't get
> around to splitting up the first arg to implement that.)
>
>>> In the ssl-cache example, the name of the mutex will be simply
>>> /mnt/sesscachedir/ssl-cache
>>>

In case it wasn't clear, I'm very eager to clear up/re-implement/etc.
any remaining details of this lovely mess, but I'm hoping that more
minds will show up and then converge to something (anything) on the
more subjective aspects.

trawick at gmail

Dec 1, 2009, 5:38 AM

Post #7 of 7 (606 views)
Permalink

Re: svn commit: r883712 - /httpd/httpd/trunk/docs/manual/mod/core.xml [In reply to]

On Tue, Nov 24, 2009 at 4:45 PM, Jeff Trawick <trawick [at] gmail> wrote:
> On Tue, Nov 24, 2009 at 3:00 PM, Jeff Trawick <trawick [at] gmail> wrote:
>> On Tue, Nov 24, 2009 at 1:58 PM, William A. Rowe Jr.
>> <wrowe [at] rowe-clan> wrote:
>>> Jeff Trawick wrote:
>>>>
>>>> What about an optional third argument to Mutex to indicate that the
>>>> pid should be omitted?
>>>>
>>>> Mutex default sysvsem
>>>> Mutex ssl-cache file:/mnt/sesscachedir OmitPid
>>>> etc.
>>>
>>> That seems sensible, but I'm left wondering how many different naming
>>> conventions we can fit on one directive line. Perhaps bOmitPID instead ;-)
>>> This really becomes harder to follow than the existing multiple-syntaxes.
>>>
>>> Is there any reason not to name these mutexes in MixedCase?
>>
>> I like having the mutex type name as of the filename, and mixed case
>> filenames are unexpected. Beyond that, MixedCase and the "." before
>> the pid suffix don't totally resolve readability. Modules like
>> mod_watchdog with multi-instance mutexes provide an instance string
>> which gets inserted as "-" string prior to the . pid suffix.
>>
>> If the watchdog names are heartbeat and dialup (wild guess; I didn't
>> look closely or try to configure the thing), the files would be
>>
>> logs/watchdog-callback-heartbeat.1359
>> logs/watchdog-callback-dialup.1359
>>
>> (These are both instances of the "watchdog-callback" type, which is
>> what would be specified on the Mutex directive.)
>>
>>> Is there any reason we can't invert the arg order, so that we have
>>>
>>> Mutex mutextype:name Resource [Resource ...] [OmitPid]
>>
>> Maybe it would be clearer if the optional OmitPid came before the list
>> of mutexes?
>>
>>>
>>> Of course, default could be assumed here. So the above becomes
>>>
>>> Mutex SysVSem
>>> Mutex file:/mnt/sesscachedir SSLSessionCache OmitPid
>>>
>>> (note the Resource tag can be the actual directive being mutexed, instead
>>> of an alt-name).
>>>
>>> Thoughts?
>>
>> I'm fine with putting the mechanism:dir first followed by a list of
>> mutex type names. I'm not sure about where to put the OmitPid though.
>> I guess you get used to either after a while.
>>
>> (Joe suggested "Mutex name1,name2,name3 mechanism:dir"; I didn't get
>> around to splitting up the first arg to implement that.)
>>
>>>> In the ssl-cache example, the name of the mutex will be simply
>>>> /mnt/sesscachedir/ssl-cache
>>>>
>
> In case it wasn't clear, I'm very eager to clear up/re-implement/etc.
> any remaining details of this lovely mess, but I'm hoping that more
> minds will show up and then converge to something (anything) on the
> more subjective aspects.
>

Nobody showed up, but that's okay... I plan to switch to

Mutex mutextype[:lockfiledir] [Resource ...] [OmitPid]

in the next few days unless somebody speaks up.

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads