Hallo, I am trying to install a setup like shown below ZEO_M | -- ZEO_B | | -- ZOPE | | -- ZOPE | | -- ZOPE | ... | -- ZOPE | -- ZOPE ... The ZEO_B should be a zeoclient of the ZEO_M (MainZEO). The reason for this setup ist that the ZEO_B is located in a backup computing center on the other side of our campus. When I configured the ZEO_B as a zeoclient of the ZEO_M. I comes up without problem. I've connected the first client, the connection is establisched but the server never come up. Here is the log from ZEO_B level debug 2006-05-02T08:21:45 BLATHER ZEO.zrpc (65280) connect from ('10.152.64.1', 54853): <ManagedServerConnection ('10.152.64.1', 54853)> ------ 2006-05-02T08:21:45 INFO ZEO.zrpc.Connection(S) (10.152.64.1:54853) received handshake 'Z303' ------ 2006-05-02T08:21:45 DEBUG ZEO.zrpc.Connection(S) (10.152.64.1:54853) calling getAuthProtocol() ------ 2006-05-02T08:21:45 DEBUG ZEO.zrpc.Connection(S) (10.152.64.1:54853) getAuthProtocol returns None ------ 2006-05-02T08:21:45 DEBUG ZEO.zrpc.Connection(S) (10.152.64.1:54853) calling register('main', False) ------ 2006-05-02T08:21:45 DEBUG ZEO.zrpc.Connection(S) (10.152.64.1:54853) register returns None ------ 2006-05-02T08:21:45 DEBUG ZEO.zrpc.Connection(S) (10.152.64.1:54853) calling get_info() ------ 2006-05-02T08:21:45 DEBUG ZEO.zrpc.Connection(S) (10.152.64.1:54853) get_info returns {'supportsVersions': 1, 'name': 'main (connected)', 'length'... ------ 2006-05-02T08:21:45 DEBUG ZEO.zrpc.Connection(S) (10.152.64.1:54853) calling endZeoVerify() ------ 2006-05-02T08:21:45 DEBUG ZEO.zrpc.Connection(S) (10.152.64.1:54853) calling loadEx('\x00\x00\x00\x00\x00\x00\x00\x00', '') here is the log for the zope server on ZEO_B 2006-05-02 08:21:45 INFO ZEO.ClientStorage (65292) ClientStorage (pid=65292) created RW/normal for storage: 'main' 2006-05-02 08:21:45 INFO ZEO.cache reusing persistent cache file '/data/zope/console28/var/frontend-main.zec' 2006-05-02 08:21:45 INFO ZEO.ClientStorage (65292) Testing connection <ManagedClientConnection ('10.152.64.1', 8110)> 2006-05-02 08:21:45 INFO ZEO.zrpc.Connection(C) (10.152.64.1:8110) received handshake 'Z303' 2006-05-02 08:21:45 INFO ZEO.ClientStorage (65292) Server authentication protocol None 2006-05-02 08:21:45 INFO ZEO.ClientStorage (65292) Connected to storage: ('10.152.64.1', 8110) 2006-05-02 08:21:45 INFO ZEO.ClientStorage (65292) Verifying cache 2006-05-02 08:21:45 INFO ZEO.ClientStorage (65292) Waiting for cache verification to finish 2006-05-02 08:21:45 INFO ZEO.ClientStorage (65292) Waiting for cache verification to finish 2006-05-02 08:21:45 INFO ZEO.ClientStorage (65292) endVerify finishing 2006-05-02 08:21:45 INFO ZEO.ClientStorage (65292) endVerify finished ^C2006-05-02 08:22:09 INFO ZEO.ClientStorage (65292) Disconnected from storage: "('10.152.64.1', 8110)" Traceback (most recent call last): File "/usr/local/www/Zope28/lib/python/Zope2/Startup/run.py", line 56, in ? run() File "/usr/local/www/Zope28/lib/python/Zope2/Startup/run.py", line 21, in run starter.prepare() File "/usr/local/www/Zope28/lib/python/Zope2/Startup/__init__.py", line 98, in prepare self.startZope() File "/usr/local/www/Zope28/lib/python/Zope2/Startup/__init__.py", line 257, in startZope Zope2.startup() File "/usr/local/www/Zope28/lib/python/Zope2/__init__.py", line 47, in startup _startup() File "/usr/local/www/Zope28/lib/python/Zope2/App/startup.py", line 57, in startup DB = configuration.dbtab.getDatabase('/', is_root=1) File "/usr/local/www/Zope28/lib/python/DBTab/DBTab.py", line 96, in getDatabase db = self._createDatabase(name, is_root) File "/usr/local/www/Zope28/lib/python/DBTab/DBTab.py", line 113, in _createDatabase db = factory.open() File "/usr/local/www/Zope28/lib/python/Zope2/Startup/datatypes.py", line 163, in open DB = self.createDB() File "/usr/local/www/Zope28/lib/python/Zope2/Startup/datatypes.py", line 160, in createDB return ZODBDatabase.open(self) File "/usr/local/www/Zope28/lib/python/ZODB/config.py", line 103, in open version_cache_size=section.version_cache_size) File "/usr/local/www/Zope28/lib/python/ZODB/DB.py", line 239, in __init__ storage.load(z64,'') File "/usr/local/www/Zope28/lib/python/ZEO/ClientStorage.py", line 746, in load return self.loadEx(oid, version)[:2] File "/usr/local/www/Zope28/lib/python/ZEO/ClientStorage.py", line 769, in loadEx data, tid, ver = self._server.loadEx(oid, version) File "/usr/local/www/Zope28/lib/python/ZEO/ServerStub.py", line 192, in loadEx return self.rpc.call("loadEx", oid, version) File "/usr/local/www/Zope28/lib/python/ZEO/zrpc/connection.py", line 531, in call r_flags, r_args = self.wait(msgid) File "/usr/local/www/Zope28/lib/python/ZEO/zrpc/connection.py", line 638, in wait asyncore.poll(delay, self._singleton) File "/usr/local/lib/python2.4/asyncore.py", line 122, in poll r, w, e = select.select(r, w, e, timeout) KeyboardInterrupt I started it with runzope and killed it with CRTL-c. I had it once waiting for 2 hours without any difference. here is the ZEO_B config file # ZEO configuration file %define INSTANCE /data/zope/zeoproxy01 <zeo> address 8110 read-only false invalidation-queue-size 100 # pid-filename $INSTANCE/var/ZEO.pid # monitor-address PORT # transaction-timeout SECONDS </zeo> <zeoclient main> server 10.152.64.1:8100 storage main name main # var $INSTANCE/var # client zeoproxy01 # cache-size 600MB </zeoclient> <eventlog> level debug <logfile> path $INSTANCE/log/zeo.log </logfile> </eventlog> <runner> program $INSTANCE/bin/runzeo socket-name $INSTANCE/etc/zeo.zdsock daemon true forever false backoff-limit 10 exit-codes 0, 2 directory $INSTANCE default-to-interactive true # user zope python /usr/local/bin/python zdrun /usr/local/www/Zope28/lib/python/zdaemon/zdrun.py # This logfile should match the one in the zeo.conf file. # It is used by zdctl's logtail command, zdrun/zdctl doesn't write it. logfile $INSTANCE/log/zeo.log </runner> The Zope Server directly on ZEO_M works without problems. Regards Estartu ---------------------------------------------------------------------------- Gerhard Schmidt | Nick : estartu IRC : Estartu | Fischbachweg 3 | | PGP Public Key 86856 Hiltenfingen | EMail: estartu@augusta.de | on request Germany | |
--On 2. Mai 2006 08:31:17 +0200 Gerhard Schmidt <estartu@ze.tum.de> wrote:
Hallo,
I am trying to install a setup like shown below
ZEO_M | -- ZEO_B | | -- ZOPE | | -- ZOPE | | -- ZOPE | ... | -- ZOPE | -- ZOPE ...
You are trying to create a cascade of multiple ZEO Clients? That looks very odd. Usually a ZEO client talks directly to a ZEO server. -aj -- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: info@zopyx.com - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope & Plone development, Consulting
On Tue, May 02, 2006 at 08:51:12AM +0200, Andreas Jung wrote:
--On 2. Mai 2006 08:31:17 +0200 Gerhard Schmidt <estartu@ze.tum.de> wrote:
Hallo,
I am trying to install a setup like shown below
ZEO_M | -- ZEO_B | | -- ZOPE | | -- ZOPE | | -- ZOPE | ... | -- ZOPE | -- ZOPE ...
You are trying to create a cascade of multiple ZEO Clients? That looks very odd. Usually a ZEO client talks directly to a ZEO server.
I try to reduce the load of the line between the backup Computing Center and the Mainsite by having a zeo server as Proxy between the zope server at the backup site an the ZEO at the main site. Secound part is that the zeo at the backupsite can easily reconfigured in a normal ZEO when the mainsite is offline. So I don't have to reconfigure all zeoclients at the backupsite. The Data.fs is copied every hour to the backup site so that a have an up to one our backup of the data.fs in case of a desaster at the main site. A configuration like that is described in the Zope Book on page 230. Besides I have found that with a growing number of zeo clients the Zeo server gets slower but neither the CPU nor the Harddisk IO is at the limit. We have a load of 0.2 to 0.3 and disk IO arrond 2-3 MB/sec. We have 12 zeoclients at the moment and 12 more are planed for the backup site. Regards Estartu ---------------------------------------------------------------------------- Gerhard Schmidt | Nick : estartu IRC : Estartu | Fischbachweg 3 | | PGP Public Key 86856 Hiltenfingen | EMail: estartu@augusta.de | on request Germany | |
--On 2. Mai 2006 09:52:57 +0200 Gerhard Schmidt <estartu@ze.tum.de> wrote:
A configuration like that is described in the Zope Book on page 230.
I can not see anything like that in the Zope Book 2.7 edition. As said a ZEO client talks to a *ZEO server* and *not* to another *ZEO client*. Anything else makes no sense. When you're look for HA solution then checkout ZRS (see on zope.com). -aj -- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: info@zopyx.com - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope & Plone development, Consulting
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2 May 2006, at 08:52, Gerhard Schmidt wrote:
A configuration like that is described in the Zope Book on page 230.
I'd like to see that. The proxying you describe is simply not possible, period. As Andreas mentioned, the (commercial) ZRS product from Zope Corp will give the the "hot backup/hot standby" you seem to look for. All "backup" ZEO servers can be accessed by clients, but read-only. jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEVx8IRAx5nvEhZLIRAkqnAJ973dfiJnM68Pw/Cym1pQvG3h7ddACfT6Oj ZEkv3PzqNUlZ2aIrGTSz2fk= =5/6J -----END PGP SIGNATURE-----
Jens Vagelpohl wrote:
On 2 May 2006, at 08:52, Gerhard Schmidt wrote:
A configuration like that is described in the Zope Book on page 230.
I'd like to see that. The proxying you describe is simply not possible, period.
He's decribing the dead tree version of the Zope Book. Either Amos or Mike decided to put in some vapourware about how ZEO worked. It is there, I have a copy and can show you if you like... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gerhard Schmidt wrote:
I try to reduce the load of the line between the backup Computing Center and the Mainsite by having a zeo server as Proxy between the zope server at the backup site an the ZEO at the main site.
Secound part is that the zeo at the backupsite can easily reconfigured in a normal ZEO when the mainsite is offline. So I don't have to reconfigure all zeoclients at the backupsite. The Data.fs is copied every hour to the backup site so that a have an up to one our backup of the data.fs in case of a desaster at the main site.
A configuration like that is described in the Zope Book on page 230.
Besides I have found that with a growing number of zeo clients the Zeo server gets slower but neither the CPU nor the Harddisk IO is at the limit. We have a load of 0.2 to 0.3 and disk IO arrond 2-3 MB/sec. We have 12 zeoclients at the moment and 12 more are planed for the backup site.
I would look for a replication strategy to create your "intermediate" storage server: the setup you are trying is not supported by the current ZEO setup. Such strategies include: - Zope Corp's "Zope Replication Services" product, which keeps the "secondary" storage servers synchronized with the primary via the "spread" toolkit. - DirectoryStorage can be used to do replication via rsync. - Another possibility would be to use 'repozo' to create deltas on the primary, and then propagate them to the secondary via rsync, then apply them via 'repozo'. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEV2ts+gerLs4ltQ4RApCyAKDCTzo6kVPfAuQZzEH+wNGOE3mfngCcCdgO qTKufl2WQwfLfxVUnj6z5KA= =zu9D -----END PGP SIGNATURE-----
On Tue, May 02, 2006 at 10:23:40AM -0400, Tres Seaver wrote:
I would look for a replication strategy to create your "intermediate" storage server: the setup you are trying is not supported by the current ZEO setup. Such strategies include:
- Zope Corp's "Zope Replication Services" product, which keeps the "secondary" storage servers synchronized with the primary via the "spread" toolkit.
- DirectoryStorage can be used to do replication via rsync.
... but you can't use a DirectoryStorage replica as a "hot" or "warm" backup. DirectoryStorage replicas are pulled from the master storage, and no storage process can be using the replica storage while this pull is happening - not even in read-only mode. This is documented at http://dirstorage.sourceforge.net/replica.html For more background discussion, see these threads - why hot failover won't work: http://sourceforge.net/mailarchive/forum.php?thread_id=4906719&forum_id=9987 some talk about cold failover: http://sourceforge.net/mailarchive/forum.php?thread_id=7828511&forum_id=9987 -- Paul Winkler http://www.slinkp.com
Tres Seaver wrote:
- Another possibility would be to use 'repozo' to create deltas on the primary, and then propagate them to the secondary via rsync, then apply them via 'repozo'.
Hi Tres. I have also been investigating strategies but had not thought of this possibility. I am not sure how you would keep the master in sync if changes are being made on a local network and also on a remote server (master). Wouldn't this result in conflicts if the data were exchange back with the master? Regards, David
--On 2. Mai 2006 12:38:28 -0300 David Pratt <fairwinds@eastlink.ca> wrote:
Tres Seaver wrote:
- Another possibility would be to use 'repozo' to create deltas on the primary, and then propagate them to the secondary via rsync, then apply them via 'repozo'.
Hi Tres. I have also been investigating strategies but had not thought of this possibility. I am not sure how you would keep the master in sync if changes are being made on a local network and also on a remote server (master).
repozo does not help you syncing multiple ZEO server..it just performs an incremental backup of an existing Data.fs file. And I don't know of any solution have multiple "master" ZEO servers. There can be only one. -aj -- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: info@zopyx.com - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope & Plone development, Consulting
Andreas Jung wrote:
repozo does not help you syncing multiple ZEO server..it just performs an incremental backup of an existing Data.fs file. And I don't know of any solution have multiple "master" ZEO servers. There can be only one.
-aj
For sure. I guess the best one could have would be replicated storage clients that when offline could operate on their own data. When they go online they would first attempt resolve their data with the (master) server (synchronizing), and then append each new transaction to the local replica as it was occuring (replicating) so that before you went offline again, your storage is up to date. I think this is all possible with a sync server, each client having an independent asynchronous loop for synchronizing, and a synchronization protocol for two way syncing. Zope has most of this now but it was never designed to provide data to the local storage to keep it up to date (while the zeo client is being used). This would be quite handy and I think there are some possibilities to do this. I guess in a general way, this is what the spread is doing for ZRS but the mechanism and use case is different. I don't think you'd want any client to be offline for long with this service with a replicated storage client. I think the idea is more of a hot backup in case of failure of the main storage but I know little of ZRS. Regards David
If the objective is to have a second ZEO server available as a hot-backup, how about the idea of having ZEO clients with the ability to write to two separate ZEO servers (ideally running on separate hardware servers) with a single 'write' command? We can accomplish this at the application level, but it would be a nice option to have ZEO do it automatically. Is this a reasonable extension to ZEO? Jonathan ----- Original Message ----- From: "David Pratt" <fairwinds@eastlink.ca> To: "Andreas Jung" <lists@zopyx.com> Cc: "Tres Seaver" <tseaver@palladion.com>; <zope@zope.org> Sent: Tuesday, May 02, 2006 1:31 PM Subject: Re: [Zope] Re: Zeo as a Zeo Client
Andreas Jung wrote:
repozo does not help you syncing multiple ZEO server..it just performs an incremental backup of an existing Data.fs file. And I don't know of any solution have multiple "master" ZEO servers. There can be only one.
-aj
For sure. I guess the best one could have would be replicated storage clients that when offline could operate on their own data. When they go online they would first attempt resolve their data with the (master) server (synchronizing), and then append each new transaction to the local replica as it was occuring (replicating) so that before you went offline again, your storage is up to date.
I think this is all possible with a sync server, each client having an independent asynchronous loop for synchronizing, and a synchronization protocol for two way syncing. Zope has most of this now but it was never designed to provide data to the local storage to keep it up to date (while the zeo client is being used). This would be quite handy and I think there are some possibilities to do this.
I guess in a general way, this is what the spread is doing for ZRS but the mechanism and use case is different. I don't think you'd want any client to be offline for long with this service with a replicated storage client. I think the idea is more of a hot backup in case of failure of the main storage but I know little of ZRS.
Regards David _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Pratt wrote:
Andreas Jung wrote:
repozo does not help you syncing multiple ZEO server..it just performs an incremental backup of an existing Data.fs file. And I don't know of any solution have multiple "master" ZEO servers. There can be only one.
-aj
For sure. I guess the best one could have would be replicated storage clients that when offline could operate on their own data. When they go online they would first attempt resolve their data with the (master) server (synchronizing), and then append each new transaction to the local replica as it was occuring (replicating) so that before you went offline again, your storage is up to date.
I think this is all possible with a sync server, each client having an independent asynchronous loop for synchronizing, and a synchronization protocol for two way syncing. Zope has most of this now but it was never designed to provide data to the local storage to keep it up to date (while the zeo client is being used). This would be quite handy and I think there are some possibilities to do this.
I guess in a general way, this is what the spread is doing for ZRS but the mechanism and use case is different. I don't think you'd want any client to be offline for long with this service with a replicated storage client. I think the idea is more of a hot backup in case of failure of the main storage but I know little of ZRS.
ZRS secondaries go into "recovery mode" whenever they lose connection with the promary: that recovery is sufficient to allow it to resync (even to bring up a new, "empty" secondary). Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEV7xH+gerLs4ltQ4RAnP3AJ9PGvYV1l4fqA9Sx1bnobr/ri4FYACdE1V9 ym8LhU8go+za7q15k7y5NSs= =tTh+ -----END PGP SIGNATURE-----
Tres Seaver wrote:
ZRS secondaries go into "recovery mode" whenever they lose connection with the promary: that recovery is sufficient to allow it to resync (even to bring up a new, "empty" secondary).
Hi Tres. This is sort of how I envisioned ZRS (though I have never seen or used it). I thought that perhaps being offline for a good length of time (or bringing up a fresh new client) would put strain on the server and increase the risk of other replication clients being blocked by the process. I am not sure how many clients are typically configured with ZRS though or whether this would be an issue. Regards, David
On Tue, May 02, 2006 at 10:23:40AM -0400, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Gerhard Schmidt wrote:
I try to reduce the load of the line between the backup Computing Center and the Mainsite by having a zeo server as Proxy between the zope server at the backup site an the ZEO at the main site.
Secound part is that the zeo at the backupsite can easily reconfigured in a normal ZEO when the mainsite is offline. So I don't have to reconfigure all zeoclients at the backupsite. The Data.fs is copied every hour to the backup site so that a have an up to one our backup of the data.fs in case of a desaster at the main site.
A configuration like that is described in the Zope Book on page 230.
Besides I have found that with a growing number of zeo clients the Zeo server gets slower but neither the CPU nor the Harddisk IO is at the limit. We have a load of 0.2 to 0.3 and disk IO arrond 2-3 MB/sec. We have 12 zeoclients at the moment and 12 more are planed for the backup site.
I would look for a replication strategy to create your "intermediate" storage server: the setup you are trying is not supported by the current ZEO setup. Such strategies include:
- Zope Corp's "Zope Replication Services" product, which keeps the "secondary" storage servers synchronized with the primary via the "spread" toolkit.
- DirectoryStorage can be used to do replication via rsync.
- Another possibility would be to use 'repozo' to create deltas on the primary, and then propagate them to the secondary via rsync, then apply them via 'repozo'.
I have never said that I want to have an realtime replaication. All I want is a ZEO at the backup site that forwards the request to the main site. Thats to provide a single point where i have to change the configuartion when a desaster at the main site happens. I simply don't want to change the configuration of all zope server at the backup site which are 12 at the first step an will grow as needed. As I said. The is a notable drop in perfomance with growing number auf connected clients. even if the clients aren't fetching objekts. I think this is becaus auf the growing invalidation overhead. We have a site with many write requests. So I hoped when i have a second zeo that the performance loss can be reduced. That's the second reason for the for this setup. As i figured that the cache is implemented in the zeoclient not in the zope server itself i thought ist might get me some proxy capabilities. But thats whould have been the sugar on the Top nothing realy needed as we have a 1 GBit connect between main and backup site. The question is why is it impossible to run a zeo as a zeoclient. I can setup a zeo with a zeoclient storage i See teh invalidations coming from the backend zeo. So this part works. The part with the client connect works also. Just the connect between both is missing. And as i said such a config is descibed in the Zope Book 2.5 version on page 230. Why has the support for such configurations droped in newer versions. We are planing to purchase ZRS later this year to setup an automatic failover. But as mentioned here. We can't use the ZRS backup servers when running in normal mode becaus they are read only. So I need an setup wer I can run a normal zeo in zeoclient mode when the mainsite is online. This zeo will be shutdown and replaced by the ZRS backup when the mainsite goes down. Otherwise i have to mess with IP takeover and other very messy strategies. I'm trying to get this as simple and as stable as possible. Bye Estartu ---------------------------------------------------------------------------- Gerhard Schmidt | Nick : estartu IRC : Estartu | Fischbachweg 3 | | PGP Public Key 86856 Hiltenfingen | EMail: estartu@augusta.de | on request Germany | |
--On 3. Mai 2006 08:11:44 +0200 Gerhard Schmidt <estartu@ze.tum.de> wrote:
The question is why is it impossible to run a zeo as a zeoclient.
Because this usecase was/is never supported.
I can setup a zeo with a zeoclient storage i See teh invalidations coming from the backend zeo. So this part works. The part with the client connect works also. Just the connect between both is missing. And as i said such a config is descibed in the Zope Book 2.5 version on page 230.
We don't have a paper copy at hand. I can not find any description of your usecase in the 2.7 edition of the Zope Book...please verify it.
Why has the support for such configurations droped in newer versions.
This was never supported. I think you are misreading something... -aj -- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: info@zopyx.com - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope & Plone development, Consulting
On Wed, May 03, 2006 at 08:22:22AM +0200, Andreas Jung wrote:
--On 3. Mai 2006 08:11:44 +0200 Gerhard Schmidt <estartu@ze.tum.de> wrote:
The question is why is it impossible to run a zeo as a zeoclient.
Because this usecase was/is never supported.
I can setup a zeo with a zeoclient storage i See teh invalidations coming from the backend zeo. So this part works. The part with the client connect works also. Just the connect between both is missing. And as i said such a config is descibed in the Zope Book 2.5 version on page 230.
We don't have a paper copy at hand. I can not find any description of your usecase in the 2.7 edition of the Zope Book...please verify it.
It was lost in the 2.6 version of the Zope book i have scanned the Page with the Picture. See http://etustar.ze.tum.de/zopebook.jpg Bye Estartu ---------------------------------------------------------------------------- Gerhard Schmidt | Nick : estartu IRC : Estartu | Fischbachweg 3 | | PGP Public Key 86856 Hiltenfingen | EMail: estartu@augusta.de | on request Germany | |
--On 3. Mai 2006 08:35:48 +0200 Gerhard Schmidt <estartu@ze.tum.de> wrote:
It was lost in the 2.6 version of the Zope book i have scanned the Page with the Picture. See http://etustar.ze.tum.de/zopebook.jpg
Scary...no idea why it is in the printed edition...at least the 2.6 and 2.7 edition does not show such a setup. As mention earlier such a setup is not supported and not supposed to work. *At least* it is *extremely* uncommon. -aj -- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: info@zopyx.com - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope & Plone development, Consulting
On Wed, May 03, 2006 at 08:56:28AM +0200, Andreas Jung wrote:
--On 3. Mai 2006 08:35:48 +0200 Gerhard Schmidt <estartu@ze.tum.de> wrote:
It was lost in the 2.6 version of the Zope book i have scanned the Page with the Picture. See http://etustar.ze.tum.de/zopebook.jpg
Scary...no idea why it is in the printed edition...at least the 2.6 and 2.7 edition does not show such a setup. As mention earlier such a setup is not supported and not supposed to work. *At least* it is *extremely* uncommon.
Every major innovation was extremely uncommon bevor it was implemented. So thats not a reason not to do it. Is there a way to get this to work. I Think it whould be a very nice feature. Because it whould increase the scalability. When we can bring the cache to work it will improve perfomance for large sites as well. Bye Estartu ---------------------------------------------------------------------------- Gerhard Schmidt | Nick : estartu IRC : Estartu | Fischbachweg 3 | | PGP Public Key 86856 Hiltenfingen | EMail: estartu@augusta.de | on request Germany | |
--On 3. Mai 2006 09:15:45 +0200 Gerhard Schmidt <estartu@ze.tum.de> wrote:
Every major innovation was extremely uncommon bevor it was implemented. So thats not a reason not to do it. Is there a way to get this to work. I Think it whould be a very nice feature. Because it whould increase the scalability. When we can bring the cache to work it will improve perfomance for large sites as well.
There are lot of things that would be nice if they were implemented.. The best chance to get this feature into Zope is either to implement it yourself or by funding the development. -aj
On Wed, May 03, 2006 at 09:19:31AM +0200, Andreas Jung wrote:
--On 3. Mai 2006 09:15:45 +0200 Gerhard Schmidt <estartu@ze.tum.de> wrote:
Every major innovation was extremely uncommon bevor it was implemented. So thats not a reason not to do it. Is there a way to get this to work. I Think it whould be a very nice feature. Because it whould increase the scalability. When we can bring the cache to work it will improve perfomance for large sites as well.
There are lot of things that would be nice if they were implemented.. The best chance to get this feature into Zope is either to implement it yourself or by funding the development.
If I had the Time I whould do it. My ToDo List goes around up to the moon an back twice. About the funding I have to talk to my superior when he is back from his vacation. Bye Estartu ---------------------------------------------------------------------------- Gerhard Schmidt | Nick : estartu IRC : Estartu | Fischbachweg 3 | | PGP Public Key 86856 Hiltenfingen | Privat: estartu@augusta.de | auf Anfrage/ Tel: 08232 77 36 4 | Dienst: schmidt@ze.tu-muenchen.de | on request Fax: 08232 77 36 3 | |
Gerhard Schmidt wrote:
If I had the Time I whould do it. My ToDo List goes around up to the moon an back twice. About the funding I have to talk to my superior when he is back from his vacation.
Bear in mind that you will need serious amounts of cash to get this implemented. This is a massive massive change. I'd suggest the money is better spent to purchasing yourself a ZRS license ;-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Gerhard Schmidt wrote at 2006-5-2 09:52 +0200:
... I try to reduce the load of the line between the backup Computing Center and the Mainsite by having a zeo server as Proxy between the zope server at the backup site an the ZEO at the main site.
You will gain nothing -- as ZEO does not implement a cache but forwards any request immediately to the storage. Its only task is to synchronize concurrent access to a single storage -- nothing else. -- Dieter
On Tue, May 02, 2006 at 10:24:29PM +0200, Dieter Maurer wrote:
Gerhard Schmidt wrote at 2006-5-2 09:52 +0200:
... I try to reduce the load of the line between the backup Computing Center and the Mainsite by having a zeo server as Proxy between the zope server at the backup site an the ZEO at the main site.
You will gain nothing -- as ZEO does not implement a cache but forwards any request immediately to the storage. Its only task is to synchronize concurrent access to a single storage -- nothing else.
For my primary goal this whould do perfectly. Primarily I whan't the zeo at backup site just to foward the request to the main site. All I want is the i have only one place to change the config in case of a failure at the main site. Nothing more. Everything else whould be nice to have. But still the even just forwarding does not work right now. Bye Estartu ---------------------------------------------------------------------------- Gerhard Schmidt | Nick : estartu IRC : Estartu | Fischbachweg 3 | | PGP Public Key 86856 Hiltenfingen | EMail: estartu@augusta.de | on request Germany | |
Gerhard Schmidt wrote at 2006-5-3 08:20 +0200:
On Tue, May 02, 2006 at 10:24:29PM +0200, Dieter Maurer wrote:
Gerhard Schmidt wrote at 2006-5-2 09:52 +0200:
... I try to reduce the load of the line between the backup Computing Center and the Mainsite by having a zeo server as Proxy between the zope server at the backup site an the ZEO at the main site.
You will gain nothing -- as ZEO does not implement a cache but forwards any request immediately to the storage. Its only task is to synchronize concurrent access to a single storage -- nothing else.
For my primary goal this whould do perfectly. Primarily I whan't the zeo at backup site just to foward the request to the main site. All I want is the i have only one place to change the config in case of a failure at the main site. Nothing more. Everything else whould be nice to have. But still the even just forwarding does not work right now.
Why would you want to use a ZEO server just for this relaying? Would it not be better to use a DNS name which you could remap at a central place (the DNS configuration) in case of problems? Or use a TCP forwarder. A ZEO server is definitely not appropriate just to relay requests. -- Dieter
participants (9)
-
Andreas Jung -
Chris Withers -
David Pratt -
Dieter Maurer -
Gerhard Schmidt -
Jens Vagelpohl -
Jonathan -
Paul Winkler -
Tres Seaver