Jim Jagielski wrote:
Jean-frederic Clere wrote:
Using the result of your ideas and the explaintions now I have mod_proxy
that uses the scoreboard via a scoreboard provider ;-)
Find enclosed the code.
Just one comment off the top of my head: this seems to confuse what
is the actual
Jean-frederic Clere wrote:
Using the result of your ideas and the explaintions now I have mod_proxy
that uses the scoreboard via a scoreboard provider ;-)
Find enclosed the code.
Any comments?
The next step is to write shared memory scoreboard provider.
I was thinking the scoreboard code
Jim Jagielski wrote:
at
is the actual scoreboard and what is the proxy's segment
of scoreboard space... Eg the ap_scoreboard_* stuff implies
that it's Apache's real scoreboard.
Like I said, I think this scoreboard stuff should be more generic than
just proxy. It could be renamed to avoid
Brian Akins wrote:
Jim Jagielski wrote:
at
is the actual scoreboard and what is the proxy's segment
of scoreboard space... Eg the ap_scoreboard_* stuff implies
that it's Apache's real scoreboard.
Like I said, I think this scoreboard stuff should be more generic
than just proxy. It could
On Jul 12, 2006, at 6:37 PM, Brian Akins wrote:
Jean-frederic Clere wrote:
Hi,
I am still trying to replace the scoreboard by shared memory to store
the shared information of the workers, I am now thinking to get
this by
adding modules like the prototype I have enclosed (that is a patch
Jim Jagielski wrote:
If this is data that needs to be accessed from non-proxy modules
then yes, I agree.
A basic API could look like. By worker, I am thinking about the mpm
sense, not the proxy sense. I guess slot may be a better term:
/*used for ap_scoreboard_do. mem is the memory
Brian Akins wrote:
Thoughts. Somthing very similar to this is used by several very busy
web sites...
+1. For example, a memcached based scoreboard would be
pretty cool ;)
--
===
Jim Jagielski [|] [EMAIL
Jim Jagielski wrote:
Brian Akins wrote:
Thoughts. Somthing very similar to this is used by several very busy
web sites...
+1. For example, a memcached based scoreboard would be
pretty cool ;)
I meant capable not necessarily based
--
Jim Jagielski wrote:
+1. For example, a memcached based scoreboard would be
pretty cool ;)
maybe in mod_scoreboard it may use a provider mechanism to actually
implement the scoreboard. Maybe have an ap_scoreboard_create_ex where
you could explicitly name a provider.
--
Brian Akins
Brian Akins wrote:
Jim Jagielski wrote:
+1. For example, a memcached based scoreboard would be
pretty cool ;)
maybe in mod_scoreboard it may use a provider mechanism to actually
implement the scoreboard. Maybe have an ap_scoreboard_create_ex where
you could explicitly name a
Jim Jagielski wrote:
Yeah, that's what I was thinking as well!
default could just use apr_shm.
--
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies
Jim Jagielski wrote:
Brian Akins wrote:
Jim Jagielski wrote:
+1. For example, a memcached based scoreboard would be
pretty cool ;)
maybe in mod_scoreboard it may use a provider mechanism to actually
implement the scoreboard. Maybe have an ap_scoreboard_create_ex where
you
Brian Akins wrote:
Jim Jagielski wrote:
If this is data that needs to be accessed from non-proxy modules
then yes, I agree.
A basic API could look like. By worker, I am thinking about the mpm
sense, not the proxy sense. I guess slot may be a better term:
/*used for ap_scoreboard_do.
Jean-frederic Clere wrote:
With such an interface you assume only one process will access to one
slot... That is what the scoreboard allows.
Allowing updates from different proccesses on the same slot.
Should we have an ap_slot_read_look() and an ap_slot_unlock() for that?
No. we don't have
On Jul 13, 2006, at 11:26 AM, Jean-frederic Clere wrote:
Jim Jagielski wrote:
Brian Akins wrote:
Jim Jagielski wrote:
+1. For example, a memcached based scoreboard would be
pretty cool ;)
maybe in mod_scoreboard it may use a provider mechanism to
actually implement the scoreboard.
On Jul 13, 2006, at 11:55 AM, Jean-frederic Clere wrote:
With such an interface you assume only one process will access to
one slot... That is what the scoreboard allows.
Allowing updates from different proccesses on the same slot.
Should we have an ap_slot_read_look() and an
Jim Jagielski wrote:
Having some external (or even internal) process update
a slot that isn't its own is dangerous. And the required
locking would be slow.
In my own hacked proxy, an external healthchecker and the proxy share a
piece of shared memory that is read-only by apache and read-write
Brian Akins wrote:
Jean-frederic Clere wrote:
With such an interface you assume only one process will access to one
slot... That is what the scoreboard allows.
Allowing updates from different proccesses on the same slot.
Should we have an ap_slot_read_look() and an ap_slot_unlock() for that?
Brian Akins wrote:
Jim Jagielski wrote:
Having some external (or even internal) process update
a slot that isn't its own is dangerous. And the required
locking would be slow.
In my own hacked proxy, an external healthchecker and the proxy share
a piece of shared memory that is read-only
Brian Akins wrote:
Jim Jagielski wrote:
If this is data that needs to be accessed from non-proxy modules
then yes, I agree.
A basic API could look like. By worker, I am thinking about the mpm
sense, not the proxy sense. I guess slot may be a better term:
/*used for ap_scoreboard_do.
Hi,
I am still trying to replace the scoreboard by shared memory to store
the shared information of the workers, I am now thinking to get this by
adding modules like the prototype I have enclosed (that is a patch
against trunk).
Does this look to be the right way to go? Or has someone a
Jean-frederic Clere wrote:
Hi,
I am still trying to replace the scoreboard by shared memory to store
the shared information of the workers, I am now thinking to get this by
adding modules like the prototype I have enclosed (that is a patch
against trunk).
We really need a generic scoreboard
Brian Akins wrote:
Jean-frederic Clere wrote:
Hi,
I am still trying to replace the scoreboard by shared memory to store
the shared information of the workers, I am now thinking to get this by
adding modules like the prototype I have enclosed (that is a patch
against trunk).
We really need
23 matches
Mail list logo
