shared memory problem on network

--===============0409200624==
Content-Type: multipart/alternative; boundary="0-1764555266-1185195735=:95859"
Content-Transfer-Encoding: 7bit

--0-1764555266-1185195735=:95859
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Bill/Bryan et al.,
=20
I was trying to implement the reader-writers locking mechanism using sh=
ared memory. I am using IPC::Shareable to implement this.
The apache-instances are currently running on only an individual server (=
say A1) and all are able to access this shared memory; and things work ju=
st fine.=20
=20
But on "live/production" environment, there are 4-5 servers (say, the o=
thers are A2, A3, A4 and A5 respectively); each running several instances=
of Apache-mod-perl.

Right now the shared memory is only on A1.=20
So if A1 goes down (due to any reason), all my other applications would=
be starved as the shared memory was implemented on A1 and all instances =
across all the servers were accessing this shared memory.
=20
Is there any way I can have a shared memory mutually accessible to all =
the servers?
So that in case A1 goes down, some other server can take take control of =
the shared memory.
Any pointers would be much appreciated.
=20
Thanks n regrds,
Ukh
=20

=20
---------------------------------
Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's =
on, when.=20
--0-1764555266-1185195735=:95859
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

RE: shared memory problem on network

From: activeperl-bounces@listserv.ActiveState.com
[mailto:activeperl-bounces@listserv.ActiveState.com] On Behalf Of ukhas
jean
Sent: 23 July 2007 14:02
To: Active Perl
Subject: shared memory problem on network

> Hi Bill/Bryan et al.,
> =

> I was trying to implement the reader-writers locking mechanism using
shared memory. I am using IPC::Shareable =

> to implement this.
> The apache-instances are currently running on only an individual
server (say A1) and all are able to access =

> this shared memory; and things work just fine. =

> =

> But on "live/production" environment, there are 4-5 servers (say, the
others are A2, A3, A4 and A5 =

> respectively); each running several instances of Apache-mod-perl.
> =

> Right now the shared memory is only on A1. =

> So if A1 goes down (due to any reason), all my other applications
would be starved as the shared memory was =

> implemented on A1 and all instances across all the servers were
accessing this shared memory.
> =

> Is there any way I can have a shared memory mutually accessible to all
the servers?
> So that in case A1 goes down, some other server can take take control
of the shared memory.
> Any pointers would be much appreciated.

AFAIK, shared memory only works for processes on the same server.

>From your description, what you actually want is a distributed locking
mechanism. Shared memory, i.e. how you wanted to implement it, is
actually a red herring. If you were to search CPAN for something like
"distributed lock" you might see a couple of modules that might help
such as IPC::Lock and IPC::Locker. Note that they don't seem to work on
all platforms.

HTH

-- =

Brian Raven =


==================== =====3D=
================
Atos Euronext Market Solutions Disclaimer
==================== =====3D=
================

The information contained in this e-mail is confidential and solely for the=
intended addressee(s). Unauthorised reproduction, disclosure, modification=
, and/or distribution of this email may be unlawful.
If you have received this email in error, please notify the sender immediat=
ely and delete it from your system. The views expressed in this message do =
not necessarily reflect those of Atos Euronext Market Solutions.

Atos Euronext Market Solutions Limited - Registered in England & Wales with=
registration no. 3962327. Registered office address at 25 Bank Street Lon=
don E14 5NQ United Kingdom. =

Atos Euronext Market Solutions SAS - Registered in France with registration=
no. 425 100 294. Registered office address at 6/8 Boulevard Haussmann 750=
09 Paris France.

L'information contenue dans cet e-mail est confidentielle et uniquement des=
tinee a la (aux) personnes a laquelle (auxquelle(s)) elle est adressee. Tou=
te copie, publication ou diffusion de cet email est interdite. Si cet e-mai=
l vous parvient par erreur, nous vous prions de bien vouloir prevenir l'exp=
editeur immediatement et d'effacer le e-mail et annexes jointes de votre sy=
steme. Le contenu de ce message electronique ne represente pas necessaireme=
nt la position ou le point de vue d'Atos Euronext Market Solutions.
Atos Euronext Market Solutions Limited Soci=E9t=E9 de droit anglais, enregi=
str=E9e au Royaume Uni sous le num=E9ro 3962327, dont le si=E8ge social se =
situe 25 Bank Street E14 5NQ Londres Royaume Uni.

Atos Euronext Market Solutions SAS, soci=E9t=E9 par actions simplifi=E9e, e=
nregistr=E9 au registre dui commerce et des soci=E9t=E9s sous le num=E9ro 4=
25 100 294 RCS Paris et dont le si=E8ge social se situe 6/8 Boulevard Hauss=
mann 75009 Paris France.
==================== =====3D=
================

_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Re: shared memory problem on network

Brian Raven wrote:
>
>>Hi Bill/Bryan et al.,
>>
>>I was trying to implement the reader-writers locking mechanism using
>
> shared memory. I am using IPC::Shareable
>
>>to implement this.
>>The apache-instances are currently running on only an individual
>
> server (say A1) and all are able to access
>
>>this shared memory; and things work just fine.
>>
>>But on "live/production" environment, there are 4-5 servers (say, the
>
> others are A2, A3, A4 and A5
>
>>respectively); each running several instances of Apache-mod-perl.
>>
>>Right now the shared memory is only on A1.
>>So if A1 goes down (due to any reason), all my other applications
>
> would be starved as the shared memory was
>
>>implemented on A1 and all instances across all the servers were
>
> accessing this shared memory.
>
>>
>>Is there any way I can have a shared memory mutually accessible to all
>
> the servers?
>
>>So that in case A1 goes down, some other server can take take control
>
> of the shared memory.
>
>>Any pointers would be much appreciated.
>
>
> AFAIK, shared memory only works for processes on the same server.

In the historical definition, that would make sense. You could, I suppose,
think of sharing memory across a network though if you stretched the def
a bit. Of course, that really complicates the locking process although
I believe there are *NIXs that have network locking implemented (haven't
played in that arena much lately).

>>From your description, what you actually want is a distributed locking
> mechanism. Shared memory, i.e. how you wanted to implement it, is
> actually a red herring. If you were to search CPAN for something like
> "distributed lock" you might see a couple of modules that might help
> such as IPC::Lock and IPC::Locker. Note that they don't seem to work on
> all platforms.

If you can't find something appropriate that works on whatever platforms
you have, you could consider making a TCP lock server or data server.

What are you trying to lock (I assume some sort of data file that is
being written and read at the same time) ? and is that data available
(or could it be made available) on any of the servers ?

If you serialize the requests through a single read/write TCP server,
you shouldn't need to worry about locks (assuming that one server could
handle all the traffic).

You could make the server movable too if one server went down, you could
vote in a new one to take over and periodically update all the servers
with the historical data so they wouldn't lose much on a takeover.

Give us a bit more info of what you're sharing/locking and what platforms
you have to deal with.
_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Re: shared memory problem on network

--===============1022158116==
Content-Type: multipart/alternative; boundary="0-111979846-1185262414=:71580"
Content-Transfer-Encoding: 7bit

--0-111979846-1185262414=:71580
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi, Bill/bryan et al.,
=20
The platforms used on the 5 servers (say, A1 to A5) are all flavors of Li=
nux.
We have a CMS in place; and the content is stored as parent-child relatio=
ns in a hash;
I m trying to lock this hash, so that when one user is editing content =
(say, like a textbox on a page, say form1), no other user should be able =
to modify this hash; lest we have inconsistent entries. In my case 120 se=
cs is the maximum time a user can lock a resource (for writing);
Shared memory works fine ( n superfast too) when all the apache-instanc=
es are on one server (say A1). But as part of risk-analysis, I have to co=
nsider the scenario "what if A1 goes down?? Shouldnt any of the other ser=
vers A2 to A5 handle user-driven hits meanwhile??"
I hadnt considered this scenario when designing. This is a major choke =
as of now.=20
Would you be requiring any more details Bill??=20

best,
Ukh
=20
Bill Luebkert wrote:
Brian Raven wrote:
>=20
>>Hi Bill/Bryan et al.,
>>=20
>>I was trying to implement the reader-writers locking mechanism using
>=20
> shared memory. I am using IPC::Shareable=20
>=20
>>to implement this.
>>The apache-instances are currently running on only an individual
>=20
> server (say A1) and all are able to access=20
>=20
>>this shared memory; and things work just fine.=20
>>=20
>>But on "live/production" environment, there are 4-5 servers (say, the
>=20
> others are A2, A3, A4 and A5=20
>=20
>>respectively); each running several instances of Apache-mod-perl.
>>
>>Right now the shared memory is only on A1.=20
>>So if A1 goes down (due to any reason), all my other applications
>=20
> would be starved as the shared memory was=20
>=20
>>implemented on A1 and all instances across all the servers were
>=20
> accessing this shared memory.
>=20
>>=20
>>Is there any way I can have a shared memory mutually accessible to all
>=20
> the servers?
>=20
>>So that in case A1 goes down, some other server can take take control
>=20
> of the shared memory.
>=20
>>Any pointers would be much appreciated.
>=20
>=20
> AFAIK, shared memory only works for processes on the same server.

In the historical definition, that would make sense. You could, I suppose=
,
think of sharing memory across a network though if you stretched the def
a bit. Of course, that really complicates the locking process although
I believe there are *NIXs that have network locking implemented (haven't
played in that arena much lately).

>>From your description, what you actually want is a distributed locking
> mechanism. Shared memory, i.e. how you wanted to implement it, is
> actually a red herring. If you were to search CPAN for something like
> "distributed lock" you might see a couple of modules that might help
> such as IPC::Lock and IPC::Locker. Note that they don't seem to work on
> all platforms.

If you can't find something appropriate that works on whatever platforms
you have, you could consider making a TCP lock server or data server.

What are you trying to lock (I assume some sort of data file that is
being written and read at the same time) ? and is that data available
(or could it be made available) on any of the servers ?

If you serialize the requests through a single read/write TCP server,
you shouldn't need to worry about locks (assuming that one server could
handle all the traffic).

You could make the server movable too if one server went down, you could
vote in a new one to take over and periodically update all the servers
with the historical data so they wouldn't lose much on a takeover.

Give us a bit more info of what you're sharing/locking and what platforms
you have to deal with.
_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs


=20
---------------------------------
Boardwalk for $500? In 2007? Ha!=20
Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! G=
ames.
--0-111979846-1185262414=:71580
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Re: shared memory problem on network

VGhpcyBpcyBhIGNsYXNzaWMgcHJvYmxlbSwgeW91IHdpbGwgaGF2ZSB0byB1 c2UgYSBzaGFyZWQg
bWVkaXVtICwgYmUgaXQgCkRCIHdpdGggdGFibGUgbG9ja3MgICxORlMgd2l0 aCBmaWxlIGxvY2tz
CiBvciB5b3VyIGNob2ljZSBvZiBuZXQgZ2x1ZS4KCkJpbGwncyBvbiB0aGUg bW9uZXkgY29tbWVu
dHMgZGVsZXRlZCAuLi4KCk8vSCB1a2hhcyBqZWFuIN3j8eH45ToKPiBIaSwg QmlsbC9icnlhbiBl
dCBhbC4sCj4KPiBUaGUgcGxhdGZvcm1zIHVzZWQgb24gdGhlIDUgc2VydmVy cyAoc2F5LCBBMSB0
byBBNSkgYXJlIGFsbCBmbGF2b3JzIG9mIAo+IExpbnV4Lgo+IFdlIGhhdmUg YSBDTVMgaW4gcGxh
Y2U7IGFuZCB0aGUgY29udGVudCBpcyBzdG9yZWQgYXMgcGFyZW50LWNoaWxk IAo+IHJlbGF0aW9u
cyBpbiBhIGhhc2g7Cj4gSSBtIHRyeWluZyB0byBsb2NrIHRoaXMgaGFzaCwg c28gdGhhdCB3aGVu
IG9uZSB1c2VyIGlzIGVkaXRpbmcgY29udGVudCAKPiAoc2F5LCBsaWtlIGEg dGV4dGJveCBvbiBh
IHBhZ2UsIHNheSBmb3JtMSksIG5vIG90aGVyIHVzZXIgc2hvdWxkIGJlIAo+ IGFibGUgdG8gbW9k
aWZ5IHRoaXMgaGFzaDsgbGVzdCB3ZSBoYXZlIGluY29uc2lzdGVudCBlbnRy aWVzLiBJbiBteSAK
PiBjYXNlIDEyMCBzZWNzIGlzIHRoZSBtYXhpbXVtIHRpbWUgYSB1c2VyIGNh biBsb2NrIGEgcmVz
b3VyY2UgKGZvciAKPiB3cml0aW5nKTsKPiBTaGFyZWQgbWVtb3J5IHdvcmtz IGZpbmUgKCBuIHN1
cGVyZmFzdCB0b28pIHdoZW4gYWxsIHRoZSAKPiBhcGFjaGUtaW5zdGFuY2Vz IGFyZSBvbiBvbmUg
c2VydmVyIChzYXkgQTEpLiBCdXQgYXMgcGFydCBvZiAKPiByaXNrLWFuYWx5 c2lzLCBJIGhhdmUg
dG8gY29uc2lkZXIgdGhlIHNjZW5hcmlvICJ3aGF0IGlmIEExIGdvZXMgZG93 bj8/IAo+IFNob3Vs
ZG50IGFueSBvZiB0aGUgb3RoZXIgc2VydmVycyBBMiB0byBBNSBoYW5kbGUg dXNlci1kcml2ZW4g
aGl0cyAKPiBtZWFud2hpbGU/PyIKPiBJIGhhZG50IGNvbnNpZGVyZWQgdGhp cyBzY2VuYXJpbyB3
aGVuIGRlc2lnbmluZy4gVGhpcyBpcyBhIG1ham9yIGNob2tlIAo+IGFzIG9m IG5vdy4KPiBXb3Vs
ZCB5b3UgYmUgcmVxdWlyaW5nIGFueSBtb3JlIGRldGFpbHMgQmlsbD8/Cj4K PiBiZXN0LAo+IFVr
aAo+CgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCkFj
dGl2ZVBlcmwgbWFpbGluZyBsaXN0CkFjdGl2ZVBlcmxAbGlzdHNlcnYuQWN0 aXZlU3RhdGUuY29t
ClRvIHVuc3Vic2NyaWJlOiBodHRwOi8vbGlzdHNlcnYuQWN0aXZlU3RhdGUu Y29tL21haWxtYW4v
bXlzdWJz

Re: shared memory problem on network

QW5nZWxvcyBLYXJhZ2Vvcmdpb3Ugd3JvdGU6Cj4gVGhpcyBpcyBhIGNsYXNz aWMgcHJvYmxlbSwg
eW91IHdpbGwgaGF2ZSB0byB1c2UgYSBzaGFyZWQgbWVkaXVtICwgYmUgaXQg Cj4gREIgd2l0aCB0
YWJsZSBsb2NrcyAgLE5GUyB3aXRoIGZpbGUgbG9ja3MKPiBvciB5b3VyIGNo b2ljZSBvZiBuZXQg
Z2x1ZS4KPiAKPiBCaWxsJ3Mgb24gdGhlIG1vbmV5IGNvbW1lbnRzIGRlbGV0 ZWQgLi4uCj4gCj4g
Ty9IIHVraGFzIGplYW4g3ePx4fjlOgo+IAo+PiBIaSwgQmlsbC9icnlhbiBl dCBhbC4sCj4+Cj4+
IFRoZSBwbGF0Zm9ybXMgdXNlZCBvbiB0aGUgNSBzZXJ2ZXJzIChzYXksIEEx IHRvIEE1KSBhcmUg
YWxsIGZsYXZvcnMgb2YgCj4+IExpbnV4Lgo+PiBXZSBoYXZlIGEgQ01TIGlu IHBsYWNlOyBhbmQg
dGhlIGNvbnRlbnQgaXMgc3RvcmVkIGFzIHBhcmVudC1jaGlsZCAKPj4gcmVs YXRpb25zIGluIGEg
aGFzaDsKPj4gSSBtIHRyeWluZyB0byBsb2NrIHRoaXMgaGFzaCwgc28gdGhh dCB3aGVuIG9uZSB1
c2VyIGlzIGVkaXRpbmcgY29udGVudCAKPj4gKHNheSwgbGlrZSBhIHRleHRi b3ggb24gYSBwYWdl
LCBzYXkgZm9ybTEpLCBubyBvdGhlciB1c2VyIHNob3VsZCBiZSAKPj4gYWJs ZSB0byBtb2RpZnkg
dGhpcyBoYXNoOyBsZXN0IHdlIGhhdmUgaW5jb25zaXN0ZW50IGVudHJpZXMu IEluIG15IAo+PiBj
YXNlIDEyMCBzZWNzIGlzIHRoZSBtYXhpbXVtIHRpbWUgYSB1c2VyIGNhbiBs b2NrIGEgcmVzb3Vy
Y2UgKGZvciAKPj4gd3JpdGluZyk7Cj4+IFNoYXJlZCBtZW1vcnkgd29ya3Mg ZmluZSAoIG4gc3Vw
ZXJmYXN0IHRvbykgd2hlbiBhbGwgdGhlIAo+PiBhcGFjaGUtaW5zdGFuY2Vz IGFyZSBvbiBvbmUg
c2VydmVyIChzYXkgQTEpLiBCdXQgYXMgcGFydCBvZiAKPj4gcmlzay1hbmFs eXNpcywgSSBoYXZl
IHRvIGNvbnNpZGVyIHRoZSBzY2VuYXJpbyAid2hhdCBpZiBBMSBnb2VzIGRv d24/PyAKPj4gU2hv
dWxkbnQgYW55IG9mIHRoZSBvdGhlciBzZXJ2ZXJzIEEyIHRvIEE1IGhhbmRs ZSB1c2VyLWRyaXZl
biBoaXRzIAo+PiBtZWFud2hpbGU/PyIKPj4gSSBoYWRudCBjb25zaWRlcmVk IHRoaXMgc2NlbmFy
aW8gd2hlbiBkZXNpZ25pbmcuIFRoaXMgaXMgYSBtYWpvciBjaG9rZSAKPj4g YXMgb2Ygbm93Lgo+
PiBXb3VsZCB5b3UgYmUgcmVxdWlyaW5nIGFueSBtb3JlIGRldGFpbHMgQmls bD8/CgpJIGhhdmVu
J3Qga2VwdCB1cCB3aXRoIHdoYXQncyBjdXJyZW50bHkgYXZhaWxhYmxlIHdp dGggTGludXggZm9y
IG5ldHdvcmsKZmlsZSBsb2NraW5nIChvdGhlciB0aGFuIE5GUyBOTE0pLiAg SSBwZXJzb25hbGx5
IHByZWZlciB0aGUgc2luZ2xlIHNlcnZlcgpjb25jZXB0IHdpdGggYSBmYWls dXJlIG1lY2hhbmlz
bSB0byBoYW5kbGUgdGhpbmdzIHdoZW4gdGhlIHNlcnZlciBnb2VzIGRvd24u CgpORlMgTkxNIHdv
dWxkIGJlIGVhc2llciB0aGFuIHNldHRpbmcgdXAgYSBzZXJ2ZXIgSSB3b3Vs ZCB0aGluay4gIEkn
bSBub3QKc3VyZSBpZiBQZXJsIGhhcyB0aGUgY29ycmVjdCBzdXBwb3J0IGZv ciBORlMgbmV0d29y
ayBsb2NrcyB5ZXQsIGJ1dCBpdCBtYXkKZGVwZW5kIG9uIGhvdyBpdCdzIGJ1 aWx0LiAgV2l0aCB0
aGUgc3RhdGUgaW5mbyBvbiBWNCwgbWFuZGF0b3J5IGxvY2tzIGNhbgpiZSBt YWRlIGlmIHlvdSBo
YXZlIGFjY2VzcyB0byBpdCB3aXRoIFBlcmwuCgpFaXRoZXIgd2F5LCB5b3Ug d291bGQgbmVlZCB0
byBoYXZlIGEgc2Vjb25kYXJ5IHNlcnZlciB3aXRoIGEgY3VycmVudCBEQgpm b3Igd2hlbiB0aGUg
bWFpbiBzZXJ2ZXIgZ29lcyBkb3duIC0gd2hpY2ggd2lsbCByZXF1aXJlIGFk ZGl0aW9uYWwgbG9n
aWMuCgpTb21lIG1hbiBwYWdlIHN0dWZmOgoKcGVybGZhcTU6CgogICBIb3cg Y2FuIEkgbG9jayBh
IGZpbGU/CiAgICAgUGVybCdzIGJ1aWx0aW4gZmxvY2soKSBmdW5jdGlvbiAo c2VlIHBlcmxmdW5j
IGZvciBkZXRhaWxzKSB3aWxsIGNhbGwKICAgICBmbG9jaygyKSBpZiB0aGF0 IGV4aXN0cywgZmNu
dGwoMikgaWYgaXQgZG9lc24ndCAob24gcGVybCB2ZXJzaW9uIDUuMDA0IGFu ZAogICAgIGxhdGVy
KSwgYW5kIGxvY2tmKDMpIGlmIG5laXRoZXIgb2YgdGhlIHR3byBwcmV2aW91 cyBzeXN0ZW0gY2Fs
bHMgZXhpc3RzLiBPbgogICAgIHNvbWUgc3lzdGVtcywgaXQgbWF5IGV2ZW4g dXNlIGEgZGlmZmVy
ZW50IGZvcm0gb2YgbmF0aXZlIGxvY2tpbmcuIEhlcmUgYXJlCiAgICAgc29t ZSBnb3RjaGFzIHdp
dGggUGVybCdzIGZsb2NrKCk6CgogICAgIDEgICBQcm9kdWNlcyBhIGZhdGFs IGVycm9yIGlmIG5v
bmUgb2YgdGhlIHRocmVlIHN5c3RlbSBjYWxscyAob3IgdGhlaXIgY2xvc2UK ICAgICAgICAgZXF1
aXZhbGVudCkgZXhpc3RzLgoKICAgICAyICAgbG9ja2YoMykgZG9lcyBub3Qg cHJvdmlkZSBzaGFy
ZWQgbG9ja2luZywgYW5kIHJlcXVpcmVzIHRoYXQgdGhlCiAgICAgICAgIGZp bGVoYW5kbGUgYmUg
b3BlbiBmb3Igd3JpdGluZyAob3IgYXBwZW5kaW5nLCBvciByZWFkL3dyaXRp bmcpLgoKICAgICAz
ICAgU29tZSB2ZXJzaW9ucyBvZiBmbG9jaygpIGNhbid0IGxvY2sgZmlsZXMg b3ZlciBhIG5ldHdv
cmsgKGUuZy4gb24gTkZTCiAgICAgICAgIGZpbGUgc3lzdGVtcyksIHNvIHlv dSdkIG5lZWQgdG8g
Zm9yY2UgdGhlIHVzZSBvZiBmY250bCgyKSB3aGVuIHlvdSBidWlsZAogICAg ICAgICBQZXJsLiBC
dXQgZXZlbiB0aGlzIGlzIGR1YmlvdXMgYXQgYmVzdC4gU2VlIHRoZSBmbG9j ayBlbnRyeSBvZiBw
ZXJsZnVuYwogICAgICAgICBhbmQgdGhlIElOU1RBTEwgZmlsZSBpbiB0aGUg c291cmNlIGRpc3Ry
aWJ1dGlvbiBmb3IgaW5mb3JtYXRpb24gb24KICAgICAgICAgYnVpbGRpbmcg UGVybCB0byBkbyB0
aGlzLgoKICAgICAgICAgVHdvIHBvdGVudGlhbGx5IG5vbi1vYnZpb3VzIGJ1 dCB0cmFkaXRpb25h
bCBmbG9jayBzZW1hbnRpY3MgYXJlIHRoYXQgaXQKICAgICAgICAgd2FpdHMg aW5kZWZpbml0ZWx5
IHVudGlsIHRoZSBsb2NrIGlzIGdyYW50ZWQsIGFuZCB0aGF0IGl0cyBsb2Nr cyBhcmUKICAgICAg
ICAgKm1lcmVseSBhZHZpc29yeSouIFN1Y2ggZGlzY3JldGlvbmFyeSBsb2Nr cyBhcmUgbW9yZSBm
bGV4aWJsZSwgYnV0IG9mZmVyCiAgICAgICAgIGZld2VyIGd1YXJhbnRlZXMu IFRoaXMgbWVhbnMg
dGhhdCBmaWxlcyBsb2NrZWQgd2l0aCBmbG9jaygpIG1heSBiZQogICAgICAg ICBtb2RpZmllZCBi
eSBwcm9ncmFtcyB0aGF0IGRvIG5vdCBhbHNvIHVzZSBmbG9jaygpLiBDYXJz IHRoYXQgc3RvcCBm
b3IKICAgICAgICAgcmVkIGxpZ2h0cyBnZXQgb24gd2VsbCB3aXRoIGVhY2gg b3RoZXIsIGJ1dCBu
b3Qgd2l0aCBjYXJzIHRoYXQgZG9uJ3QKICAgICAgICAgc3RvcCBmb3IgcmVk IGxpZ2h0cy4gU2Vl
IHRoZSBwZXJscG9ydCBtYW5wYWdlLCB5b3VyIHBvcnQncyBzcGVjaWZpYwog ICAgICAgICBkb2N1
bWVudGF0aW9uLCBvciB5b3VyIHN5c3RlbS1zcGVjaWZpYyBsb2NhbCBtYW5w YWdlcyBmb3IgZGV0
YWlscy4gSXQncwogICAgICAgICBiZXN0IHRvIGFzc3VtZSB0cmFkaXRpb25h bCBiZWhhdmlvciBp
ZiB5b3UncmUgd3JpdGluZyBwb3J0YWJsZSBwcm9ncmFtcy4KICAgICAgICAg KElmIHlvdSdyZSBu
b3QsIHlvdSBzaG91bGQgYXMgYWx3YXlzIGZlZWwgcGVyZmVjdGx5IGZyZWUg dG8gd3JpdGUgZm9y
CiAgICAgICAgIHlvdXIgb3duIHN5c3RlbSdzIGlkaW9zeW5jcmFzaWVzIChz b21ldGltZXMgY2Fs
bGVkICJmZWF0dXJlcyIpLiBTbGF2aXNoCiAgICAgICAgIGFkaGVyZW5jZSB0 byBwb3J0YWJpbGl0
eSBjb25jZXJucyBzaG91bGRuJ3QgZ2V0IGluIHRoZSB3YXkgb2YgeW91cgog ICAgICAgICBnZXR0
aW5nIHlvdXIgam9iIGRvbmUuKQoKICAgICAgICAgRm9yIG1vcmUgaW5mb3Jt YXRpb24gb24gZmls
ZSBsb2NraW5nLCBzZWUgYWxzbyAiRmlsZSBMb2NraW5nIiBpbgogICAgICAg ICBwZXJsb3BlbnR1
dCBpZiB5b3UgaGF2ZSBpdCAobmV3IGZvciA1LjYpLgpfX19fX19fX19fX19f X19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXwpBY3RpdmVQZXJsIG1haWxpbmcgbGlz dApBY3RpdmVQZXJs
QGxpc3RzZXJ2LkFjdGl2ZVN0YXRlLmNvbQpUbyB1bnN1YnNjcmliZTogaHR0 cDovL2xpc3RzZXJ2
LkFjdGl2ZVN0YXRlLmNvbS9tYWlsbWFuL215c3Vicw==

Re: shared memory problem on network

--===============1136147051==
Content-Type: multipart/alternative; boundary="0-1163220268-1186149876=:58769"
Content-Transfer-Encoding: 7bit

--0-1163220268-1186149876=:58769
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Bill/bryan et al.
=20
I am running"lockerd" and have written a client script which uses IPC::=
Locker.
The client is able to "switch" servers (in case any one server is down =
using the same module.
=20
Thanks guys !
=20
--Ukh=20

Bill Luebkert wrote:
Brian Raven wrote:
>=20
>>Hi Bill/Bryan et al.,
>>=20
>>I was trying to implement the reader-writers locking mechanism using
>=20
> shared memory. I am using IPC::Shareable=20
>=20
>>to implement this.
>>The apache-instances are currently running on only an individual
>=20
> server (say A1) and all are able to access=20
>=20
>>this shared memory; and things work just fine.=20
>>=20
>>But on "live/production" environment, there are 4-5 servers (say, the
>=20
> others are A2, A3, A4 and A5=20
>=20
>>respectively); each running several instances of Apache-mod-perl.
>>
>>Right now the shared memory is only on A1.=20
>>So if A1 goes down (due to any reason), all my other applications
>=20
> would be starved as the shared memory was=20
>=20
>>implemented on A1 and all instances across all the servers were
>=20
> accessing this shared memory.
>=20
>>=20
>>Is there any way I can have a shared memory mutually accessible to all
>=20
> the servers?
>=20
>>So that in case A1 goes down, some other server can take take control
>=20
> of the shared memory.
>=20
>>Any pointers would be much appreciated.
>=20
>=20
> AFAIK, shared memory only works for processes on the same server.

In the historical definition, that would make sense. You could, I suppose=
,
think of sharing memory across a network though if you stretched the def
a bit. Of course, that really complicates the locking process although
I believe there are *NIXs that have network locking implemented (haven't
played in that arena much lately).

>>From your description, what you actually want is a distributed locking
> mechanism. Shared memory, i.e. how you wanted to implement it, is
> actually a red herring. If you were to search CPAN for something like
> "distributed lock" you might see a couple of modules that might help
> such as IPC::Lock and IPC::Locker. Note that they don't seem to work on
> all platforms.

If you can't find something appropriate that works on whatever platforms
you have, you could consider making a TCP lock server or data server.

What are you trying to lock (I assume some sort of data file that is
being written and read at the same time) ? and is that data available
(or could it be made available) on any of the servers ?

If you serialize the requests through a single read/write TCP server,
you shouldn't need to worry about locks (assuming that one server could
handle all the traffic).

You could make the server movable too if one server went down, you could
vote in a new one to take over and periodically update all the servers
with the historical data so they wouldn't lose much on a takeover.

Give us a bit more info of what you're sharing/locking and what platforms
you have to deal with.
_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs


=20
---------------------------------
Luggage? GPS? Comic books?=20
Check out fitting gifts for grads at Yahoo! Search.
--0-1163220268-1186149876=:58769
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Re: shared memory problem on network

Hi Bill/bryan et al.

I was planning to load-test my daemon service
"lockerd" which is running as the lock-server on my
network.

I cant seem to find a starting-point on how to achieve
this. Any pointers would really help.

Best regards,
Ukh




--- ukhas jean wrote:

> Hi Bill/bryan et al.
>
> I am running"lockerd" and have written a client
> script which uses IPC::Locker.
> The client is able to "switch" servers (in case
> any one server is down using the same module.
>
> Thanks guys !
>
> --Ukh
>
> Bill Luebkert wrote:
> Brian Raven wrote:
> >
> >>Hi Bill/Bryan et al.,
> >>
> >>I was trying to implement the reader-writers
> locking mechanism using
> >
> > shared memory. I am using IPC::Shareable
> >
> >>to implement this.
> >>The apache-instances are currently running on only
> an individual
> >
> > server (say A1) and all are able to access
> >
> >>this shared memory; and things work just fine.
> >>
> >>But on "live/production" environment, there are
> 4-5 servers (say, the
> >
> > others are A2, A3, A4 and A5
> >
> >>respectively); each running several instances of
> Apache-mod-perl.
> >>
> >>Right now the shared memory is only on A1.
> >>So if A1 goes down (due to any reason), all my
> other applications
> >
> > would be starved as the shared memory was
> >
> >>implemented on A1 and all instances across all the
> servers were
> >
> > accessing this shared memory.
> >
> >>
> >>Is there any way I can have a shared memory
> mutually accessible to all
> >
> > the servers?
> >
> >>So that in case A1 goes down, some other server
> can take take control
> >
> > of the shared memory.
> >
> >>Any pointers would be much appreciated.
> >
> >
> > AFAIK, shared memory only works for processes on
> the same server.
>
> In the historical definition, that would make sense.
> You could, I suppose,
> think of sharing memory across a network though if
> you stretched the def
> a bit. Of course, that really complicates the
> locking process although
> I believe there are *NIXs that have network locking
> implemented (haven't
> played in that arena much lately).
>
> >>From your description, what you actually want is a
> distributed locking
> > mechanism. Shared memory, i.e. how you wanted to
> implement it, is
> > actually a red herring. If you were to search CPAN
> for something like
> > "distributed lock" you might see a couple of
> modules that might help
> > such as IPC::Lock and IPC::Locker. Note that they
> don't seem to work on
> > all platforms.
>
> If you can't find something appropriate that works
> on whatever platforms
> you have, you could consider making a TCP lock
> server or data server.
>
> What are you trying to lock (I assume some sort of
> data file that is
> being written and read at the same time) ? and is
> that data available
> (or could it be made available) on any of the
> servers ?
>
> If you serialize the requests through a single
> read/write TCP server,
> you shouldn't need to worry about locks (assuming
> that one server could
> handle all the traffic).
>
> You could make the server movable too if one server
> went down, you could
> vote in a new one to take over and periodically
> update all the servers
> with the historical data so they wouldn't lose much
> on a takeover.
>
> Give us a bit more info of what you're
> sharing/locking and what platforms
> you have to deal with.
> _______________________________________________
> ActivePerl mailing list
> ActivePerl@listserv.ActiveState.com
> To unsubscribe:
> http://listserv.ActiveState.com/mailman/mysubs
>
>
>
> ---------------------------------
> Luggage? GPS? Comic books?
> Check out fitting gifts for grads at Yahoo!
Search.>
_______________________________________________
> ActivePerl mailing list
> ActivePerl@listserv.ActiveState.com
> To unsubscribe:
http://listserv.ActiveState.com/mailman/mysubs




____________________________________________________________ ________________________
Sick sense of humor? Visit Yahoo! TV's
Comedy with an Edge to see what's on, when.
http://tv.yahoo.com/collections/222
_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs