Thread: [Modeling-users] Modeling v0.9 released!
Status: Abandoned
Brought to you by:
sbigaret
Menu
▾
▴
modeling-users
|
From:
<sbi...@us...> - 2006-02-26 19:12:35
|
Hi all, After a loooooong time, I'm pleased to announce that version 0.9 is final= ly packaged and released. You'll find it, as usual, on the sourceforge's projet page. It contains an important fix for a bug recently discovered, causing myste= rious failures when the framework is heavily stressed in a multi-threaded= environment. Obviously it also contains all the fixes that were put on the main trunk = since 0.9pre17.1 was released, see CHANGES for details (https://sf.net/pr= oject/shownotes.php?group_id=3D58935&release_id=3D396880). Some already reported bugs remain, they'll be addressed in a future relea= se. By the way: the sources are now under subversion control; good bye cvs! a= nd a big thank you to the sf.net's team. Last, the release is again under a 3-clause BSD license, as it had been p= reviously announced here. -- S=E9bastien. |
|
From: Paul M. <pau...@ma...> - 2006-03-03 18:05:12
|
Greetings, In the process of starting my zope server, getting this error: ------ 2006-03-03T10:29:05 ERROR(200) Products.ZEditingContextSessioning The session data container's destruction callback already set -- installation aborted ------ My config is: OSX Tiger python 2.3.5 Zope 2.7.6 Modeling-0.9 ZModeling-0.9 I have a zeoclient(1)/zeoserver setup and I used <http:// longsleep.org/howto/sharesessionwithzeo> for configuration of the session storage. Also getting the same error with previous version. Any ideas? Paul |
|
From:
<sbi...@us...> - 2006-03-03 20:52:13
Attachments:
ZECS.patch
|
Hi Paul,
Paul Mylchreest wrote :
> Greetings,
>=20
> In the process of starting my zope server, getting this error:
>=20
> ------
> 2006-03-03T10:29:05 ERROR(200) Products.ZEditingContextSessioning The
> session data container's destruction callback already set --
> installation aborted
> ------
The message you get is a security mechanism.
It notifies you that an other Product (or maybe you) already set the dest=
ruction callback of the sessions data container.
The ZECS (ZEditingContextSessionning) decides not to override it when it =
is already set, because if you (or another Product) already rely on it, s=
ome special action needs to be taken (namely: calling the already registe=
red callback before or after ZECS's one).
Frankly, you're the 1st person reporting such a collision; I suspect that=
the zeo configuration is the reason.
Could you please tell us which callback is registered: in the ZMI, go to =
/temp_folder/session_data and look at the value entered under the field '=
Script to call when objects are deleted' ? I appreciate your time --hope=
fully we'll quickly find a fix for the problem.
In the meantime, if you want to try the ZECS despite the problem, just ap=
ply the attached patch: the installation won't be stopped because of that=
situation. Be aware, however, that the patch shouldn't be installed in =
a production environment if you're using SESSION.defaultEditingContext: i=
f the deletion hook is not properly installed, then a session's EC will n=
ever be garnaged collected when a session expires, causing the memory foo=
tprint to grow, and grow, and grow!
In a test/dev environment this should not be a problem however.
-- S=E9bastien.
> My config is:
> OSX Tiger
> python 2.3.5
> Zope 2.7.6
> Modeling-0.9
> ZModeling-0.9
>=20
> I have a zeoclient(1)/zeoserver setup and I used
> <http://longsleep.org/howto/sharesessionwithzeo> for configuration of
> the session storage. Also getting the same error with previous version.
>=20
> Any ideas?
>=20
> Paul
|
|
From: Paul M. <pau...@ma...> - 2006-03-03 21:27:02
|
Hi S=E9bastien, On 3-Mar-06, at 15:50 , S=E9bastien Bigaret wrote: > Hi Paul, > > Paul Mylchreest wrote : >> Greetings, >> >> In the process of starting my zope server, getting this error: >> >> ------ >> 2006-03-03T10:29:05 ERROR(200) Products.ZEditingContextSessioning The >> session data container's destruction callback already set -- >> installation aborted >> ------ > > The message you get is a security mechanism. > > It notifies you that an other Product (or maybe you) already set =20 > the destruction callback of the sessions data container. > The ZECS (ZEditingContextSessionning) decides not to override it =20 > when it is already set, because if you (or another Product) already =20= > rely on it, some special action needs to be taken (namely: calling =20 > the already registered callback before or after ZECS's one). > > Frankly, you're the 1st person reporting such a collision; I =20 > suspect that the zeo configuration is the reason. > > Could you please tell us which callback is registered: in the ZMI, =20 > go to /temp_folder/session_data and look at the value entered under =20= > the field 'Script to call when objects are deleted' ? I appreciate =20= > your time --hopefully we'll quickly find a fix for the problem. > The registered callback is: "/Control_Panel/Products/=20 ZEditingContextSessioning/sessionDeletion_hook" Starting to understand what happened. At some point, I split my dev =20 server into a zeoserver config, but with ZECS already installed. Here's what I did: uninstall ZECS, clear the callback and reinstall. =20 Restarting Zope, no error and the callback is set. Next, create another zeoclient and start it: now I get the security =20 warning. I think this is happening because the session is now stored in zodb =20 storage, and not in the instance's home temp storage. Thanks for your help S=E9bastien, > In the meantime, if you want to try the ZECS despite the problem, =20 > just apply the attached patch: the installation won't be stopped =20 > because of that situation. Be aware, however, that the patch =20 > shouldn't be installed in a production environment if you're using =20 > SESSION.defaultEditingContext: if the deletion hook is not properly =20= > installed, then a session's EC will never be garnaged collected =20 > when a session expires, causing the memory footprint to grow, and =20 > grow, and grow! > > In a test/dev environment this should not be a problem however. > > -- S=E9bastien. Paul,= |
|
From:
<sbi...@us...> - 2006-03-03 23:30:24
Attachments:
ZECS.2.patch
|
Thanks for all the precisions; this is definitely a situation that should= be detected and handled by the product.=20 I've opened ticket #1442766 for that. http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1442766&grou= p_id=3D58935&atid=3D489335 If you have some time, could you try the attached patch (replacing the on= e sent earlier) ? I've had some tests and more zLog statements: I've no zeo env. at hand, I= have no time for trying to set up one and I do not have any real experie= nce w/ zeo environments, so if you could install this patch and report th= e observed logs for the second zeoclient, that will be a great help for m= e to fully understand how zeo works. In particular, I'd like to determin= e whether TransientObject is also shared and correctly setup or not --I t= hink it is not, and, well, we'd better be sure! or the second, 3rd etc. z= eo instances won't have any SESSION.defaultEditiingContext. -- S=E9bastien. PS: LOG statements at the INFO level for the purpose of verifications --t= hey should be DEBUG or BLATHER when committed. Paul Mylchreest a =E9crit : > Hi S=E9bastien, >=20 > On 3-Mar-06, at 15:50 , S=E9bastien Bigaret wrote: >=20 >> Hi Paul, >> >> Paul Mylchreest wrote : >>> Greetings, >>> >>> In the process of starting my zope server, getting this error: >>> >>> ------ >>> 2006-03-03T10:29:05 ERROR(200) Products.ZEditingContextSessioning The >>> session data container's destruction callback already set -- >>> installation aborted >>> ------ >> >> The message you get is a security mechanism. >> >> It notifies you that an other Product (or maybe you) already set the >> destruction callback of the sessions data container. >> The ZECS (ZEditingContextSessionning) decides not to override it when >> it is already set, because if you (or another Product) already rely on >> it, some special action needs to be taken (namely: calling the already >> registered callback before or after ZECS's one). >> >> Frankly, you're the 1st person reporting such a collision; I suspect >> that the zeo configuration is the reason. >> >> Could you please tell us which callback is registered: in the ZMI, go >> to /temp_folder/session_data and look at the value entered under the >> field 'Script to call when objects are deleted' ? I appreciate your >> time --hopefully we'll quickly find a fix for the problem. >> >=20 > The registered callback is: > "/Control_Panel/Products/ZEditingContextSessioning/sessionDeletion_hook= " >=20 > Starting to understand what happened. At some point, I split my dev > server into a zeoserver config, but with ZECS already installed. >=20 > Here's what I did: uninstall ZECS, clear the callback and reinstall. > Restarting Zope, no error and the callback is set. >=20 > Next, create another zeoclient and start it: now I get the security > warning. >=20 > I think this is happening because the session is now stored in zodb > storage, and not in the instance's home temp storage. >=20 > Thanks for your help S=E9bastien, >=20 >> In the meantime, if you want to try the ZECS despite the problem, just >> apply the attached patch: the installation won't be stopped because of >> that situation. Be aware, however, that the patch shouldn't be >> installed in a production environment if you're using >> SESSION.defaultEditingContext: if the deletion hook is not properly >> installed, then a session's EC will never be garnaged collected when a >> session expires, causing the memory footprint to grow, and grow, and >> grow! >> >> In a test/dev environment this should not be a problem however. >> >> -- S=E9bastien. >=20 >=20 > Paul, |
|
From: Paul M. <pau...@ma...> - 2006-03-04 00:21:48
|
Hi again, I applied the patch and here are the logs (I deleted the registered =20 callback): <server 1> ------ 2006-03-03T18:53:40 INFO(0) Products.ZEditingContextSessioning Adding =20= a 'defaultEditingContext' attribute to TransientObject ------ 2006-03-03T18:53:40 INFO(0) Products.ZEditingContextSessioning Adding =20= a 'defaultEditingContext' attribute to TransientObject ------ 2006-03-03T18:53:40 INFO(0) Products.ZEditingContextSessioning =20 Product's Control Panel: Properties tab already initialized ------ 2006-03-03T18:53:40 INFO(0) Zope Ready to handle requests </server 1> <server 2> ------ 2006-03-03T18:54:15 INFO(0) Products.ZEditingContextSessioning =20 session's deletion hook already registered ------ 2006-03-03T18:54:15 INFO(0) Products.ZEditingContextSessioning Adding =20= a 'defaultEditingContext' attribute to TransientObject ------ 2006-03-03T18:54:15 INFO(0) Products.ZEditingContextSessioning =20 Product's Control Panel: Properties tab already initialized ------ 2006-03-03T18:54:15 INFO(0) Zope Ready to handle requests </server 2> Also, when tracing defaultEditingContext(), each server seems to =20 return a different EC. Server1: session.id: 11414313110001400458 ec: =20 <Modeling.EditingContext.EditingContext object at 0x284b0f0> Server2: session.id: 11414313110001400458 ec: =20 <Modeling.EditingContext.EditingContext object at 0x26bb9d0> Thanks, Paul On 3-Mar-06, at 18:28 , S=E9bastien Bigaret wrote: > Thanks for all the precisions; this is definitely a situation that =20 > should be detected and handled by the product. > > I've opened ticket #1442766 for that. > http://sourceforge.net/tracker/index.php?=20 > func=3Ddetail&aid=3D1442766&group_id=3D58935&atid=3D489335 > > If you have some time, could you try the attached patch (replacing =20 > the one sent earlier) ? > > I've had some tests and more zLog statements: I've no zeo env. at =20 > hand, I have no time for trying to set up one and I do not have any =20= > real experience w/ zeo environments, so if you could install this =20 > patch and report the observed logs for the second zeoclient, that =20 > will be a great help for me to fully understand how zeo works. In =20 > particular, I'd like to determine whether TransientObject is also =20 > shared and correctly setup or not --I think it is not, and, well, =20 > we'd better be sure! or the second, 3rd etc. zeo instances won't =20 > have any SESSION.defaultEditiingContext. > > -- S=E9bastien. > > > PS: LOG statements at the INFO level for the purpose of =20 > verifications --they should be DEBUG or BLATHER when committed. |
|
From:
<sbi...@us...> - 2006-03-04 13:26:41
|
Paul Mylchreest a =E9crit : > Hi again, >=20 > I applied the patch and here are the logs (I deleted the registered > callback): [...] Ok, thanks > Also, when tracing defaultEditingContext(), each server seems to return > a different EC. >=20 > Server1: session.id: 11414313110001400458 ec: > <Modeling.EditingContext.EditingContext object at 0x284b0f0> > Server2: session.id: 11414313110001400458 ec: > <Modeling.EditingContext.EditingContext object at 0x26bb9d0> >=20 Oh well, I guess the documentation lacks an important paragraph here. The ZECS is designed to work in a MT environment, not in different instances. That's why you get this, hopefully you noticed it. The fact is that, you cannot share EC between different processes (so this is not specific to zeo itself). To do such a thing, it would be necessary to store the EC in the session along with its pending insertions/deletions, and the whole graph of objects as well since pending modifications can exist in-memory. It is not possible in the current implementation, and there is no plan for making this available (for example, in the zope/zeo case, this means that every single object and their attributes should be made zodb-Persistent so that they can be stored in a session object). In fact, Zope/zeo & zodb address the same problem by opening and closing a transaction changes at the beginning/end of each request loop. If you need to hold back changes between two or three requests/pages, you won't change the real object in the "main" zodb, rather you'll store the changes in a session object. - If every changes made in a request loop is committed/rolled back at the end of the request, then you'll made changes directly in the object. You can do the same w/ ZECS: this is why it has an option binding EC-transactions to zope transactions, cf. http://modeling.sf.net/UserGuide/framework-integration-zope-options.html - on the other hand, if the modifications of, say, a given objet should be made accross different requests/pages before being permanently stored in a db (either zodb, or rdbms), you'll just make it the usual way; e.g. storing the changes in a session-object, then in the last page, committing the changes into the object and the DB. -> This is because you have different python instances (processes) that you lose the ability to have persisting changes accross requests in the objects handled by an EC. Now of course, if you can make sure that a given session is always served by the same zeoclient, then you'll get back the "full power" of having a session-EC, with pending (uncommitted) changes crossing the page requests. But I do not know if this is possible w/ zope/zeo. I hope I managed to be clear in my explanations. And I'll add a paragraph making this explicit in the documentation. -- S=E9bastien. > Thanks, > Paul >=20 > On 3-Mar-06, at 18:28 , S=E9bastien Bigaret wrote: >=20 >> Thanks for all the precisions; this is definitely a situation that >> should be detected and handled by the product. >> >> I've opened ticket #1442766 for that. >> http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1442766&g= roup_id=3D58935&atid=3D489335 >> >> >> If you have some time, could you try the attached patch (replacing the >> one sent earlier) ? >> >> I've had some tests and more zLog statements: I've no zeo env. at >> hand, I have no time for trying to set up one and I do not have any >> real experience w/ zeo environments, so if you could install this >> patch and report the observed logs for the second zeoclient, that will >> be a great help for me to fully understand how zeo works. In >> particular, I'd like to determine whether TransientObject is also >> shared and correctly setup or not --I think it is not, and, well, we'd >> better be sure! or the second, 3rd etc. zeo instances won't have any >> SESSION.defaultEditiingContext. >> >> -- S=E9bastien. >> >> >> PS: LOG statements at the INFO level for the purpose of verifications >> --they should be DEBUG or BLATHER when committed. >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting lang= uage > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding territ= ory! > http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=121642 > _______________________________________________ > Modeling-users mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/modeling-users >=20 >=20 |
|
From: Paul M. <pau...@ma...> - 2006-03-08 17:55:02
|
Salut S=E9bastien, On 4-Mar-06, at 08:25 , S=E9bastien Bigaret wrote: > Now of course, if you can make sure that a given session is always > served by the same zeoclient, then you'll get back the "full power" of > having a session-EC, with pending (uncommitted) changes crossing the > page requests. But I do not know if this is possible w/ zope/zeo. > I'm using the "pound" load balancer. It has a feature that allows to =20 redirect requests to a zeoclient on per session basis (by IP or =20 user), thus solving that problem. The only thing missing is =20 notification of changes between EC's and was wondering if you have =20 had any requests for this? > I hope I managed to be clear in my explanations. And I'll add a > paragraph making this explicit in the documentation. > Yes. Thanks for clearing this up. Your explanation was very clear. Cheers, Paul, |
|
From:
<sbi...@us...> - 2006-03-13 08:35:12
|
Paul Mylchreest wrote: > Salut S=E9bastien, >=20 [...] > I'm using the "pound" load balancer. It has a feature that allows to > redirect requests to a zeoclient on per session basis (by IP or user), > thus solving that problem. Good to know there is a simple solution for this. I'll add it in the documentation as well. If you don't mind, I'll probably ask you privately about some more details about the pound setup when I'm writing the documentation for this. [ For the archives: I've found pound at: http://www.apsis.ch/pound ] > The only thing missing is notification of > changes between EC's and was wondering if you have had any requests for > this? No, not yet; do you think you could have some time testing the feature if we go for it? Cheers, -- S=E9bastien. |
|
From: Paul M. <pau...@ma...> - 2006-03-13 10:09:45
|
Hello S=E9bastien, On 13-Mar-06, at 03:32 , S=E9bastien Bigaret wrote: > Paul Mylchreest wrote: >> Salut S=E9bastien, >> > [...] >> I'm using the "pound" load balancer. It has a feature that allows to >> redirect requests to a zeoclient on per session basis (by IP or =20 >> user), >> thus solving that problem. > > Good to know there is a simple solution for this. I'll add it in the > documentation as well. > > If you don't mind, I'll probably ask you privately about some more > details about the pound setup when I'm writing the documentation =20 > for this. > Certainly, I would be glad to give any details about that. > [ For the archives: I've found pound at: http://www.apsis.ch/pound ] > >> The only thing missing is notification of >> changes between EC's and was wondering if you have had any =20 >> requests for >> this? > > No, not yet; do you think you could have some time testing the feature > if we go for it? > Yes. Cheers, Paul |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X