PANIC!!! That old refresh bug again.
Once again I have the problem that all references to imported modules/objects/whatever dissapear when refreshing. It seems like sometimes some modules are not refreshed, even though they really are. Could it be that not all modules are properly purged from memory, and then when Zope core calls our newly refreshed system, it calls old versions of the modules, which now have lost all connection to the outer world, since they no longer exist? Or what? Having to restart each time I make a change is slowing down my development to a complete halt. I don't have time with this, PLEASE I need all help I can get. Any stupid ideas or thoughts are welcome. I HAVE to fix this. Best Regards Lennart Regebro, Torped http://www.easypublisher.com/
Lennart Regebro wrote:
Once again I have the problem that all references to imported modules/objects/whatever dissapear when refreshing.
It seems like sometimes some modules are not refreshed, even though they really are. Could it be that not all modules are properly purged from memory, and then when Zope core calls our newly refreshed system, it calls old versions of the modules, which now have lost all connection to the outer world, since they no longer exist?
Known bug, no known way to fix it, sorry. Objects created from the old modules that stick around after refresh will suddenly be bound to the module "None". You're likely to run into this if your product does anything more than simply define and register classes that derive from SimpleItem. However, there are ways to get around this, though they are all very dependent on your particular code. Which of the following are you doing? - Using threads (other than the way Zope uses them) - Opening independent database connections - Making one product depend on another using import statements - Storing a module-level cache - Monkey-patching - others...? Shane
From: "Shane Hathaway" <shane@zope.com>
You're likely to run into this if your product does anything more than simply define and register classes that derive from SimpleItem.
Strangely enough we do this all the time, but we only get problems with the core EasyPublisher products.
Which of the following are you doing?
- Making one product depend on another using import statements - Monkey-patching - Storing a module-level cache
The we of course do tons of semi-magick things, but these we typically do in products that we don't have any problems with. :-) Best Regards Lennart Regebro, Torped http://www.easypublisher.com/
Lennart Regebro wrote:
From: "Shane Hathaway" <shane@zope.com>
You're likely to run into this if your product does anything more than simply define and register classes that derive from SimpleItem.
Strangely enough we do this all the time, but we only get problems with the core EasyPublisher products.
Which of the following are you doing?
- Making one product depend on another using import statements - Monkey-patching - Storing a module-level cache
The we of course do tons of semi-magick things, but these we typically do in products that we don't have any problems with. :-)
The first thing you need to make sure you do is set up dependencies. If FooProduct imports EasyPublisher, set FooProduct to be auto-refreshable, then visit EasyPublisher and specify the dependency. Then, every time EasyPublisher gets refreshed, FooProduct will be refreshed immediately after. Shane
From: "Shane Hathaway" <shane@zope.com>
The first thing you need to make sure you do is set up dependencies. If FooProduct imports EasyPublisher, set FooProduct to be auto-refreshable, then visit EasyPublisher and specify the dependency. Then, every time EasyPublisher gets refreshed, FooProduct will be refreshed immediately after.
Of course. I can refresh every product in the universe, but it doens't help. :-) The code called is still old, non-refreshed, and has all imports set to None. Best Regards Lennart Regebro, Torped http://www.easypublisher.com/
A new idea: Could the problem appear when you have "circular" product imports, i.e.: In Product.ProductA.ProductA.py: from Product.ProductB.SupportModule import Supportmodule In Product.ProductB.ProductB.py: from Product.ProductB.AnotherModule import AnotherModule Maybe the refresh gets confused by this? Best Regards Lennart Regebro, Torped http://www.easypublisher.com/
Lennart Regebro wrote:
A new idea:
Could the problem appear when you have "circular" product imports, i.e.:
In Product.ProductA.ProductA.py: from Product.ProductB.SupportModule import Supportmodule
In Product.ProductB.ProductB.py: from Product.ProductB.AnotherModule import AnotherModule ^^^^^^^^
I assume you mean ProductA here.
Maybe the refresh gets confused by this?
It might. In general, it's not a good thing to have circular imports in your code anyway, since it's brittle. Shane
From: "Shane Hathaway" <shane@zope.com>
I assume you mean ProductA here.
Yes.
It might. In general, it's not a good thing to have circular imports in your code anyway, since it's brittle.
They are not circular on a module-level, just on a product level, and indeed, it seems to help to factor out the common modules to a third product. :-) Best Regards Lennart Regebro, Torped http://www.easypublisher.com/
Shane Hathaway <shane@zope.com> wrote:
- Making one product depend on another using import statements
I'm doing that, and I observe the problem Lennart is describing (objects turning into None). Any idea for a workaround? Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com
Florent Guillaume writes:
Shane Hathaway <shane@zope.com> wrote:
- Making one product depend on another using import statements
I'm doing that, and I observe the problem Lennart is describing (objects turning into None). Any idea for a workaround? First refresh the "base" product, then the "depending" product.
Dieter
On Wednesday 18 Sep 2002 4:23 pm, Lennart Regebro wrote:
Having to restart each time I make a change is slowing down my development to a complete halt.
Something is wrong here. You should be able to restart Zope within a few seconds. Are you using FileStorage? I guess you are not shutting Zope down cleanly. An unclean shutdown means FileStorage needs to rebuild its in-memory index at the next startup, which is a slow process. Even with a clean shutdown that preserves the index, startup can be slower if your database is huge. Using ZEO eliminates this.
On Wed, 2002-09-18 at 13:09, Toby Dickenson wrote:
On Wednesday 18 Sep 2002 4:23 pm, Lennart Regebro wrote:
Having to restart each time I make a change is slowing down my development to a complete halt.
Something is wrong here. You should be able to restart Zope within a few seconds.
Are you using FileStorage? I guess you are not shutting Zope down cleanly. An unclean shutdown means FileStorage needs to rebuild its in-memory index at the next startup, which is a slow process.
Even with a clean shutdown that preserves the index, startup can be slower if your database is huge. Using ZEO eliminates this.
True! I had a Zope with a Huge Data.fs that took up to 5 mins to (re)start. With ZEO, this time dropped to between 2 and 10 secs. I highly recommend ZEO for development. It's great for debugging too, when you have to freeze debug Zope (i.e. inside pdb or gdb), you can keep another ZEO client running. Cheers, Leo -- Ideas don't stay in some minds very long because they don't like solitary confinement.
participants (6)
-
Dieter Maurer -
Florent Guillaume -
Lennart Regebro -
Leonardo Rochael Almeida -
Shane Hathaway -
Toby Dickenson