ConflictError with *one* ZEO client?
I've got a zopectl script I'm trying to run with the "zopectl run" command. It crashes out with a ConflictError even if there are no other ZEO clients connected to the ZEO store. I've restarted the ZEO store, no change. Any advice? Ideas? Richard
Which Zope are you using? Set the logging level to BLATHER and try running with runzope rather than zopectl and see what happens. The event log should help localize the problem. Be sure to check both the ZEO logs and the Zope logs. Also, it helps if you post the traceback. On Wed, 28 Jun 2006, Richard Jones wrote:
I've got a zopectl script I'm trying to run with the "zopectl run" command. It crashes out with a ConflictError even if there are no other ZEO clients connected to the ZEO store. I've restarted the ZEO store, no change.
Any advice? Ideas?
Richard _______________________________________________ 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 )
--
On Wednesday 28 June 2006 11:35, you wrote:
Which Zope are you using? Set the logging level to BLATHER and try running with runzope rather than zopectl and see what happens. The event log should help localize the problem. Be sure to check both the ZEO logs and the Zope logs.
Also, it helps if you post the traceback.
Quite so, I apologise for the apalling lack of detail in my post. I'm going to try to reproduce the problem in a few hours. I'll post details then. Richard
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28 Jun 2006, at 03:24, Richard Jones wrote:
I've got a zopectl script I'm trying to run with the "zopectl run" command. It crashes out with a ConflictError even if there are no other ZEO clients connected to the ZEO store. I've restarted the ZEO store, no change.
Having just one ZEO client will not mean you get no conflicts. Having more than one client just means there is a higher chance that two operations will concurrently modify the same object and cause them. If you're running a script you should tell us what the script does. jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEojnWRAx5nvEhZLIRAqz4AJ9yvOa2YaoExLHkOMKkkZDwuj9NfQCfU87Q ZIL29wrWJaci+hptUNANjdg= =CwE4 -----END PGP SIGNATURE-----
On Wednesday 28 June 2006 18:12, Jens Vagelpohl wrote:
On 28 Jun 2006, at 03:24, Richard Jones wrote:
I've got a zopectl script I'm trying to run with the "zopectl run" command. It crashes out with a ConflictError even if there are no other ZEO clients connected to the ZEO store. I've restarted the ZEO store, no change.
Having just one ZEO client will not mean you get no conflicts. Having more than one client just means there is a higher chance that two operations will concurrently modify the same object and cause them.
If you're running a script you should tell us what the script does.
The script merely modified a bunch of objects in the ZODB. Beyond that, there's not much that I can usefully tell you. I'm using Zope 2.8.5. As part of maintenance today I restarted the ZEO clients & server, while removing the ZEO caches from the clients. I can no longer reproduce the problem. Richard
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28 Jun 2006, at 10:23, Richard Jones wrote:
If you're running a script you should tell us what the script does.
The script merely modified a bunch of objects in the ZODB. Beyond that, there's not much that I can usefully tell you.
I'm using Zope 2.8.5.
As part of maintenance today I restarted the ZEO clients & server, while removing the ZEO caches from the clients. I can no longer reproduce the problem.
Are you using persistent ZEO caches? Those have been known to cause odd symptoms here and there... jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEoj52RAx5nvEhZLIRAlqxAJ4xtdV0z42St3DS1Sai1bwRU6KvEwCeOl4p xlB3Q52CTJz1xS5bMvy32AQ= =3ZwL -----END PGP SIGNATURE-----
On Wednesday 28 June 2006 18:31, Jens Vagelpohl wrote:
Are you using persistent ZEO caches? Those have been known to cause odd symptoms here and there...
What do you mean by "persistent"? I have noticed strange beahviours if I don't remove the caches when I do a full (client + server) restart. Removing the .zec files is part of my standard full restart maintenance routine now. Richard
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28 Jun 2006, at 11:13, Richard Jones wrote:
On Wednesday 28 June 2006 18:31, Jens Vagelpohl wrote:
Are you using persistent ZEO caches? Those have been known to cause odd symptoms here and there...
What do you mean by "persistent"? I have noticed strange beahviours if I don't remove the caches when I do a full (client + server) restart. Removing the .zec files is part of my standard full restart maintenance routine now.
If you look at the zeoclient stanza inside the zodb_db main section in your zope.conf you see this: # Uncomment to have a persistent disk cache #client zeo1 This option gives you a persistent ZEO disk cache, which means the cache file is retained across restarts. I assume you have that uncommented, otherwise the .zec files would not hang around. If you comment it you won't have to worry about .zec files anymore, and about odd behaviors. This option does *not* mean "use a cache at all? yes or no", it just means "keep the cache file around". jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEokmtRAx5nvEhZLIRAtjBAJ9OgccZdZA18BBLN9BiBczL1Oy77ACglem7 BQDRCxJJyPeH6D9mjCoHsj0= =Ojil -----END PGP SIGNATURE-----
Richard Jones wrote at 2006-6-28 11:24 +1000:
it crashes out with a ConflictError even if there are no other ZEO clients connected to the ZEO store.
Usually, a "ConflictError" does not crash Zope... In the past, I have seen occational "ConflictError" during product initialization (some bug). Together with the misfeature (others disagree) that in development mode (aka "debug-mode") Zope does not start when a product can not be initialized, this might explain your observation. Whenever you have startup problems, start Zope in the foreground and what the error messages. -- Dieter
On Thursday 29 June 2006 06:13, Dieter Maurer wrote:
Richard Jones wrote at 2006-6-28 11:24 +1000:
it crashes out with a ConflictError even if there are no other ZEO clients connected to the ZEO store.
Usually, a "ConflictError" does not crash Zope...
Sure, we requests are retried, but "zopectl run" doesn't do that. Since we upgraded to 2.8 we see a few ConflictErrors propogated up through to users each week. Richard
Richard Jones wrote at 2006-6-29 08:29 +1000:
... Since we upgraded to 2.8 we see a few ConflictErrors propogated up through to users each week.
Usually, this means weak application design. Good application design would make the conflict probability so low that it is very unlikely that a "ConflictError" propagates to the user. In your place, I would start investigating what causes the conflicts and look for ways to reduce their probability. -- Dieter
On Thursday 29 June 2006 18:56, Dieter Maurer wrote:
Good application design would make the conflict probability so low that it is very unlikely that a "ConflictError" propagates to the user.
For more complicated applications this is only possible with locking. Does Zope provide locking primitives? Or, ideally, something like asynchronous message passing? I would love to be able to start a transaction and, if it finishes in less than x seconds, tell the user the result or, if it hasn't finshed by then, that the transaction is being processed, please come back later. Thanks...
----- Original Message ----- From: "Berthold Stöger" <blists@bdf-net.com> To: <zope@zope.org> Cc: "Dieter Maurer" <dieter@handshake.de> Sent: Thursday, June 29, 2006 2:35 PM Subject: Re: [Zope] ConflictError with *one* ZEO client?
On Thursday 29 June 2006 18:56, Dieter Maurer wrote:
Good application design would make the conflict probability so low that it is very unlikely that a "ConflictError" propagates to the user.
For more complicated applications this is only possible with locking. Does Zope provide locking primitives?
Or, ideally, something like asynchronous message passing? I would love to be able to start a transaction and, if it finishes in less than x seconds, tell the user the result or, if it hasn't finshed by then, that the transaction is being processed, please come back later.
If you are interested in async programming with zope have a look at twisted, here's some info: http://twistedmatrix.com/projects/core/documentation/howto/index.html Jonathan
Berthold Stöger wrote at 2006-6-29 20:35 +0200:
On Thursday 29 June 2006 18:56, Dieter Maurer wrote:
Good application design would make the conflict probability so low that it is very unlikely that a "ConflictError" propagates to the user.
For more complicated applications this is only possible with locking.
For many, even complex applications, it can be done without locking.
Does Zope provide locking primitives?
The ZODB does not support locking. You can use Python's locking in Zope -- but it won't help you with "ConflictError"s.
Or, ideally, something like asynchronous message passing? I would love to be able to start a transaction and, if it finishes in less than x seconds, tell the user the result or, if it hasn't finshed by then, that the transaction is being processed, please come back later.
This can be done -- when you program it: You can start a separate thread (or process) that performs the transaction and indicates completion in some adequate way. In your request processing, you wait a given time for completion and if this time out return some message. Note that it is not easy to correctly manage separate threads. In particular, you cannot pass persistent objects between threads: the separate thread must open its own ZODB connection and must be careful to perform transaction management and release all resources when it finishes. -- Dieter
participants (6)
-
Berthold Stöger -
Dennis Allison -
Dieter Maurer -
Jens Vagelpohl -
Jonathan -
Richard Jones