[Zope-dev] product refresh and random number generation.
hi, I'm having problems with random number generation and product refreshes. To illustrate the problem, consider the following product code: class RandomNumberGenerator(SimpleItem.SimpleItem): ... def __init__(self,id): initialize an instance self.id = id self.__random = Random(time.time()) def next(self): returns next random number. return self.__random.random() ok, this works but whenever the product is refreshed or the zope server restarts, the generator will start to generate the same sequence of numbers, which is not what I want. I'm having trouble understanding what is happening: since the object gets pumped up every request it would make sense that you get the same random number if you lose some state from the internal random generator. But this isn't happening. You apparantly only lose state when the product is refreshed or when the zope server restarts. Could this be a cache effect ? (I could, as a last resort seed the generator with the current time every request, but then, I lose all guarantees about the period for the random number generation) any input appreciated. Romain. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] product refresh and random number generation.
On Tuesday 28 January 2003 11:31 am, Romain Slootmaekers wrote: I'm having trouble understanding what is happening: You are storing an instance of the Random class in ZODB, but not telling ZODB about changes to its internal state. def next(self): returns next random number. self._p_changed = 1 return self.__random.random() -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.6.0 ZMI Problem for CJK(Collector 623) patch.
On Sunday 26 January 2003 7:25 pm, Kazuya FUKAMACHI wrote: Have you decided which version the patch should be included? I combined 4 of the patches and Yousei Tahara's patch into single patch and published for japanese users on Jan 15. http://www.atransia.co.jp/home/ZenKai/Members/kafka/patch/Zope261b.patch Thanks to everyone who has helped on this. This patch is in cvs ready for 2.6.1 beta 2. Please give the beta a good work out. -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] 2.6.1b2?
BL == Brian Lloyd [EMAIL PROTECTED] writes: Here's the status - an engagement that we're doing has been bringing up some issues regarding ZODB and ZEO in large-scale environments. I think that the fixes are useful enough that they should be in 2.6.1, but getting them finalized has taken longer than I expected. I'd love to know what kind of thing 'large-scale' implies here, and what kind of problems the fixes fixed. BL Large-scale meaning large numbers of ZEO clients, that mount BL multiple ZEO-served databases that are each replicated using ZRS BL (Zope Corp.'s replication / failover solution) :^) BL The changes have to do with coordination of transaction commit BL among multiple databases, manageability and BL fault-tolerance. I'll ask Jeremy to be sure to update the BL CHANGES.txt with the important changes. I've included the current list of changes from ZODB3/NEWS.txt. I believe the list is complete, but would want Barry and Guido to double-check. The first change is possibily controversial. I think the others are fairly conservative. Jeremy The Transaction hosed feature is disabled in this release. If a transaction fails during the tpc_finish() it is not possible, in general, to know whether the storage is in a consistent state. For example, a ZEO server may commit the data and then fail before sending confirmation of the commit to the client. If multiple storages are involved in a transaction, the problem is exacerbated: One storage may commit the data while another fails to commit. In previous versions of ZODB, the database would set a global variable hosed that prevented any other transaction from committing until an administrator could check the status of the various failed storages and ensure that the database is in a consistent state. This approach favors data consistency over availability. The new approach is to log a panic but continue. In practice, availability seems to be more important than consistency. The failure mode is exceedingly rare in either case. The BTrees-based fsIndex for FileStorage is enabled. This version of the index is faster to load and store via pickle and uses less memory to store keys. We had intended to enable this feature in an earlier release, but failed to actually do it; thus, it's getting enabled as a bug fix now. Two rare bugs were fixed in BTrees conflict resolution. The most probable symptom of the bug would have been a segfault. The bugs were found via synthetic stress tests rather than bug reports. A value-based consistency checker for BTrees was added. See the module BTrees.check for the checker and other utilities for working with BTrees. ZEO --- The ZEO version number was bumped to 2.0.2 on account of the below minor feature additions. The performance of full cache verification has improved dramatically. XXX Get measurements from Jim -- somewhere in 2x-5x recall. The implementation was fixed to use the very-fast getSerial() method on the storage instead of the comparatively slow load(). The ZEO server has an optional timeout feature that will abort a connection that does not commit within a certain amount of time. The timeout works by closing the socket the client is using, causing both client and server to abort the transaction and continue. This is a drastic step, but can be useful to prevent a hung client or other bug from blocking a server indefinitely. If a client was disconnected during a transaction, the tpc_abort() call did not properly reset the internal state about the transaction. The bug caused the next transaction to fail in its tpc_finish(). ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] RE: [ZODB-Dev] False alarm (was: [BUG] maybe yet unknown BTREES bug)
[[EMAIL PROTECTED]] It has been a false alarm. Sorry! The same problem occured with the new BTrees module. Therefore, I checked the error again and found, that the problem was not caused by tree[k] = v but by a nearby del tree[k] (which, of course, is entitled to raise KeyError). When we had analysed the error for the first time, we happened to look at some slightly outdated source. I appreciate the follwup, Dieter! I've gone half blind searching the source for any way a BTree __setitem__ could have raised KeyError. I didn't find one, even if the BTree were corrupted. But that doesn't mean it couldn't happen wink, so knowing it wasn't actually happening is a relief. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
