June 2001 - Zope - Zope lists

LoginManager not installing
by tomc＠evetcia.com 22 Jun '01

22 Jun '01

I have just downloaded LoginManager-0-8-8b1.tgz and installed the product. I am using Zope 2.3.2 on FreeBSD 4.0 When I restart Zope the Login Manager Product is broken with the following message: Traceback (innermost last): File "/usr/local/Zope/2-3-0/lib/python/OFS/Application.py", line 528, in import_products product=__import__(pname, global_dict, global_dict, silly) File "/usr/local/Zope/2-3-0/lib/python/Products/LoginManager/__init__.py", line 1, in ? import LoginManager, LoginMethods, UserSources File "/usr/local/Zope/2-3-0/lib/python/Products/LoginManager/LoginManager.py", line 8, in ? from Products.ZPatterns.Specialists import Specialist File "/usr/local/Zope/2-3-0/lib/python/Products/ZPatterns/__init__.py", line 1, in ? import Rack, Specialists, Customizers, AttributeProviders, SheetProviders File "/usr/local/Zope/2-3-0/lib/python/Products/ZPatterns/Rack.py", line 9, in ? from DataSkins import DataSkin File "/usr/local/Zope/2-3-0/lib/python/Products/ZPatterns/DataSkins.py", line 1, in ? from DynPersist import DynPersist ImportError: No module named DynPersist According to the release notes all required module are included with the release. Is there something else I need installed? BTW, The ZPatterns and PlugIn modules that came in the distribution seem to have installed properly. Tom

1 0

RE: [Zope] XRON and simultaneous triggers
by Capesius, Alan 21 Jun '01

21 Jun '01

that would be the zope(a)zope.org part :) maybe you mean don't send it direct too? >>>-----Original Message----- >>>From: Loren Stafford [mailto:lstafford@morphics.com] >>>Please respond to the list so others can benefit from the exchange. >>> >>>> -----Original Message----- >>>> From: Capesius, Alan [mailto:CapesiusA@Sysmex.com] >>>> Sent: Thursday, June 21, 2001 16:07 >>>> To: Loren Stafford; zope(a)zope.org >>>> Subject: RE: [Zope] XRON and simultaneous triggers >>>>

1 0

RE: [Zope] XRON and simultaneous triggers
by Capesius, Alan 21 Jun '01

21 Jun '01

A bit more info on my crash. (NTS 4.0 SP6 Zope2.30) At the time the crash occurred, an out of virtual memory was also displayed at the server and the server had memory usage above 1GB RAM. The active python task was not consuming this (nor was anything else, but the service had been restarted at that point. Global RAM usage? I've also disabled the error dump messages so that Zope will restart itself without human intervention when it bombs. Though, in this case it was still dumping a crash dump file, which takes awhile. I've now disabled crash dumps. Since I was unable to access the server to abort or modify any methods, I was forced to restart it. This did not resolve the xron problem, as the scheduler activated immediately and started looping again. I was able to resolve this by downing the service, removing the xron folder, restarting, removing the offending ODBC/SQL call in the xron method that I suspected and restarting again with the XRon folder back in place. The offending call was a single record update to an Access DB. I am now in the process of migrating all live query functions over to SQL Server based tables. I'm not sure if the jet drivers in the O/S were bogging down. My suspicion (without much evidence) is that the Jet connection was flipping open and closed so rapidly that something got out of whack with the timing. (but that theory's more about what I don't know that what I do know :) Thanks again Loren for the excellent insights into xron. Now i just have to learn ZClasses, python, and the meaning of life.... >>>-----Original Message----- >>>From: Loren Stafford [mailto:lstafford@morphics.com] >>>Sent: Thursday, June 21, 2001 5:55 PM >>>To: Capesius, Alan; zope(a)zope.org >>>Subject: RE: [Zope] XRON and simultaneous triggers >>> >>> >>>The Xron Dispatcher executes ready events serially. This is >>>due to the fact >>>that Dispatcher consists of a single thread and fires >>>scheduled methods with >>>Client.py, so it has to wait until it gets a response from >>>Client.py before >>>it can service the next ready event. >>> >>>So I wouldn't expect to find that Xron contributes to >>>concurrency problems >>>by itself. Of course it might trigger a method that accesses >>>your database >>>at the same time that a real user is accessing the database, >>>but that should >>>be a trivial problem. >>> >>>The Dispatcher tries to avoid endless loops when something >>>goes wrong in a >>>scheduled method. First it tries to disarm the scheduled >>>method; failing >>>that, it deletes the corresponding entry from the Schedule catalog. >>> >>>It disarms the scheduled method by calling (again via >>>Client.py) disarm(), a >>>private method of the Xron DTML Method, and rescheduling the >>>method for >>>"never". Its attempt to disarm may fail, and the entries you >>>are seeing in >>>the log file show that it is failing. There are only a few >>>conditions that >>>can cause a failure at this point: insufficient priviledges >>>to execute the >>>disarm() method, incorrect URL of the method, failure of the >>>socket used by >>>Client.py, failure to update the Schedule catalog when >>>disarming the method. >>> >>>In case the Dispatcher fails to disarm a Xron DTML Method, >>>it still tries to >>>prevent looping by deleting the corresponding entry from the Schedule >>>catalog. I think the only failure that can occur at this >>>point is a Schedule >>>catalog update failure. If it can't change or delete the >>>schedule entry from >>>the catalog, it will find it there again the next time it >>>wakes up (which >>>will be immediately) and try to trigger it again. >>> >>>I don't know why it would not be possible to update the >>>Schedule at this >>>point. But I have twice seen such a failure on my system (NT >>>4, Zope 2.3.2). >>>In fact, just yesterday I received 163 email messages >>>telling me to take out >>>the garbage. 8-0 >>> >>>If anyone has any ideas about how the Dispatcher could fail >>>to disarm a >>>failed event, I'd be happy to listen. In fact, someone who >>>is familiar with >>>ZODB programming should look over the ZODB and transaction logic in >>>Dispatcher.py and check whether I am doing something wrong >>>there. I really >>>don't understand everything I wrote. 8-) >>> >>>In fact, why don't I just include it below. >>> >>>-- Loren >>> >>>##################################################################### >>>""" Dispatcher for Xron Events """ >>> >>>#The Dispatcher runs as a separate thread >>># It uses the Schedule as its primary data structure >>># It knows which event is next >>># It sleeps until that event or a change in the Schedule >>># It fires an event and logs its output >>> >>>import Loggerr >>>loggerr=Loggerr.loggerr >>>#import pdb; pdb.set_trace() >>> >>>from Globals import DateTime >>>import sys, string >>> >>>maxwait=float(10) # max time to wait between wake-ups in seconds >>> >>>def Timer(ScheduleID, ScheduleChange, rpc): # aka Dispatcher >>> #loggerr(0, 'Dispatcher thread started.') >>> # infinite loop >>> while 1: >>> # Good morning. We just woke up. >>> # The first thing we need is a new connection. >>> import Zope >>> app=Zope.app() >>> try: >>> Schedule = getattr(app, ScheduleID, None) >>> except: >>> loggerr(301, 'Cannot access catalog. Suspending operation.') >>> break >>> >>> interval=maxwait # Default sleep time. May be recalculated below >>> try: >>> (atime, aurl)=Schedule.armed_event() # Get next armed event >>> except: >>> loggerr(302,'Cannot access catalog. Suspending operation.') >>> break # out of infinite loop >>> if atime is None: >>> #loggerr(0, 'No armed events.') # debug >>> pass # Sleep some more >>> elif atime.isFuture(): # The next armed event is not yet ready >>> # calculate how long we have to wait >>> ainterval=atime.timeTime() - DateTime().timeTime() >>> if ainterval < float(0): ainterval=float(0) # Is negative bad? >>> interval=ainterval # Comment out for debugging to >>>limit to maxwait >>> else: # This event is ready now. >>> # Fire event, and log its output >>> emsg= '\nTrigger event: %s\nTrigger time: %s' % (aurl, atime) >>> furl=string.join((aurl, 'trigger'), '/') >>> try: >>> (headers,response)=rpc(furl) # Fire event >>> dmsg='%s\n' % response >>> loggerr(0, emsg, detail=dmsg) # Log the event and its output >>> except: >>> type, val, tb = sys.exc_info() >>> dmsg="Failed to trigger event.\nType=%s\nVal=%s\n" % >>>(type, val) >>> loggerr(100, emsg, detail=dmsg) >>> del type, val, tb, dmsg >>> try: >>> rpc('%s/%s' % (aurl, 'disarm')) # Attempt to disarm >>> loggerr(100, 'Disarmed event', detail='') >>> except: >>> # aurl is probably pointing to an event that no >>>longer exists >>> # or the url doesn't resolve correctly >>> loggerr(100, "Failed to disarm event", detail='') >>> # Let's just kick it out of the catalog >>> # Otherwise, this event will come back to haunt us >>> try: >>> Schedule.exterminate(aurl) >>> get_transaction().commit() >>> except: >>> pass >>> # Finished processing one event >>> app._p_jar.sync() # see ZODB/Connection.py >>> interval=float(0) >>> >>> # We're going to sleep now; so, free the connection >>> app._p_jar.close() >>> del app >>> # Sleep for predetermined interval >>> #emsg= 'Going to sleep for %s seconds' % (interval) >>> ScheduleChange.wait(interval) # in seconds (float) >>> >>> if ScheduleChange.isSet(): >>> #loggerr(0, 'Awakened by set event.') # debug >>> ScheduleChange.clear() >>> # Schedule has changed, we woke up early >>> # Loop back to the top and check for >>> # an earlier event than we were waiting for >>> #else: >>> #loggerr(0, 'Awakened by timeout.') # debug >>> # We timed out, so there must be a ready event >>> # Loop back to the top and trigger the next ready event. >>> # That's probably the one we were waiting for. >>> #pass >>> >>> # End of while 1 loop. >>> # Something bad happened, let's clean up before quitting for good >>> try: >>> app._p_jar.close() >>> del app >>> except: >>> pass >>> loggerr(100, 'Dispatcher thread is terminating.') >>> >>>============== end ================ >>>

2 1

RE: [Zope] LoginManager not installing
by tomc＠evetcia.com 21 Jun '01

21 Jun '01

I have now got one step further on this. I have discovered that I needed to build ZPatters (not explained anywhere in the LoginManager documentation - that I could find) I have done so, but now I get the following error when I look at the LoginManager product: Traceback (innermost last): File "/usr/local/Zope/2-3-0/lib/python/OFS/Application.py", line 528, in import_products product=__import__(pname, global_dict, global_dict, silly) File "/usr/local/Zope/2-3-0/lib/python/Products/LoginManager/__init__.py", line 1, in ? import LoginManager, LoginMethods, UserSources File "/usr/local/Zope/2-3-0/lib/python/Products/LoginManager/LoginManager.py", line 121, in ? raise 'InstallError', ( InstallError: No access file found at /usr/local/Zope/2-3-0 - see INSTALL.txt Sure enough I dont have an 'access' file at that location. Am I supposed to have one? Everything seems to work fine in Zope and I have never needed one before. Where would I find one? Tom => -----Original Message----- => From: zope-admin(a)zope.org [mailto:zope-admin@zope.org]On Behalf Of => tomc(a)evetcia.com => Sent: Friday, 22 June 2001 10:09 AM => To: zope(a)zope.org => Subject: [Zope] LoginManager not installing => => => I have just downloaded LoginManager-0-8-8b1.tgz and => installed the product. I am using Zope 2.3.2 on FreeBSD 4.0 => When I restart Zope the Login Manager Product is broken with => the following message: => Traceback (innermost last): => File => "/usr/local/Zope/2-3-0/lib/python/OFS/Application.py", line => 528, in import_products => product=__import__(pname, global_dict, global_dict, silly) => File => "/usr/local/Zope/2-3-0/lib/python/Products/LoginManager/__ini => t__.py", line 1, in ? => import LoginManager, LoginMethods, UserSources => File => "/usr/local/Zope/2-3-0/lib/python/Products/LoginManager/Login => Manager.py", line 8, in ? => from Products.ZPatterns.Specialists import Specialist => File => "/usr/local/Zope/2-3-0/lib/python/Products/ZPatterns/__init__ => .py", line 1, in ? => import Rack, Specialists, Customizers, => AttributeProviders, SheetProviders => File => "/usr/local/Zope/2-3-0/lib/python/Products/ZPatterns/Rack.py" => , line 9, in ? => from DataSkins import DataSkin => File => "/usr/local/Zope/2-3-0/lib/python/Products/ZPatterns/DataSkin => s.py", line 1, in ? => from DynPersist import DynPersist => ImportError: No module named DynPersist => According to the release notes all required module are => included with the release. Is there something else I need installed? => BTW, The ZPatterns and PlugIn modules that came in the => distribution seem to have installed properly. => Tom =>

2 1

XRON and simultaneous triggers
by Capesius, Alan 21 Jun '01

21 Jun '01

How does XRON handle multiple events schedule for firing at the same time? If they are parallel tasks, does this present any problems with ODBC database access if say 20 tasks were all queued to fire at the same time? I added a ODBC SQL call to my Xron Method to tag a particular record in an MSAccess database with the current date for indicating the last time a scheduled job fired. This ODBC SQL call would've been executing from multiple threads simultaneously when the events triggered through the scheduler. I'm seeing some "connection already closed" errors from zmxodbc in the xron log. This is resulting in an endless loop until the server is restarted and full system logs. 2001-06-21T18:11:51 PROBLEM(100) Products.Xron.Loggerr Failed to disarm event ------ 2001-06-21T18:11:51 PROBLEM(100) Products.Xron.Loggerr Trigger event: http://192.168.200.1:8080/Event_IConnect_Alert Trigger time: 2001/06/21 12:59:00 US/Central Failed to trigger event. Type=bci.ServerError Val=connection already closed (File: D:\Zope230\lib\python\Products\ZmxODBCDA\db.py Line: 150) 500 Internal Server Error for http://192.168.200.1:8080/Event_IConnect_Alert/trigger ------ 2001-06-21T18:11:51 PROBLEM(100) Products.Xron.Loggerr Failed to disarm event ------ 2001-06-21T18:11:51 PROBLEM(100) Products.Xron.Loggerr Trigger event: http://192.168.200.1:8080/Event_IConnect_Alert Trigger time: 2001/06/21 12:59:00 US/Central Failed to trigger event. Type=bci.ServerError Val=connection already closed (File: D:\Zope230\lib\python\Products\ZmxODBCDA\db.py Line: 150) 500 Internal Server Error for http://192.168.200.1:8080/Event_IConnect_Alert/trigger Alan Capesius, MCSE/NTCIP+20 Technical Support Engineer Sysmex Corporation of America capesiusa(a)sysmex.com

2 1

Don't treat .data as a big string.
by Kyler B. Laird 21 Jun '01

21 Jun '01

I learned my lesson for today, so I thought I'd share it. I am passing around large strings containing PDF and PS documents. Sometimes I make a call like document = container.PJdoc(container['proposal'].data) where the object "proposal" is a PDF file. I end up writing this data to a temporary file in my PJ class. I noticed early on that I could not simply write the whole string, but I worked around that by writing it in 1K blocks. I had my warning. Today my dumb kludge came back to bite me. We found that some of our proposals were rejected by the PDF parser. I started looking at the temporary files and noticed the problem ones were 98798 bytes in length. The PDF file sent was much larger. After some tests, I determined that asking for a slice from .data only returns a null string (zero length) after 98798 bytes. This meant that my little 1K write loop was happily going through the "string" but it was writing 0K blocks after awhile. So...I finally fixed the problem. Instead of all of the 1K writing junk, I simply cast whatever is passed to me into a real string. Then I can write the whole thing without any problems. I'm sure this is documented somewhere that I should have read before, but I'm hoping having it here too saves someone some grief. Thank you. --kyler

2 2

Unregistered.
by weelly 21 Jun '01

21 Jun '01

Hi all.Please delete my email andress from your mailist. Thank you.Bye-Bye

1 0

My XRON wish list
by Capesius, Alan 21 Jun '01

21 Jun '01

Things it would be helpful to have Xron DTML methods support: 1) Date last fired for each method. 2) Additional attributes for user related information (such as submitter, email, ip addr etc. to be used for site specific reporting on schedule status for advanced scheduling apps.) 3) Hours of operation for a particular task. (run on monday wednesday friday, or run between 9:00 and 17:00) Alan Capesius, MCSE/NTCIP+20 Technical Support Engineer Sysmex Corporation of America capesiusa(a)sysmex.com

2 1

How do I change unauthorized access error message
by Arnulf Heimsbakk 21 Jun '01

21 Jun '01

How do I change the unauthorized access error message in Zope? It don't seem to be the standard_error_message. --- arnulf heimsbakk system analyst +47 76 14 45 42 spirea.net - http://spirea.net andøya rocket range - http://www.rocketrange.no

2 1

LoginManager capabilities
by Carlson, Christopher W. 21 Jun '01

21 Jun '01

Well, I've seen How-Tos for using LoginManager with MySQL and PostgreSQL, but will it do non-database user managment? Specifically, if I create a user class subclassed from LoginManager:LoginUser, can I just use it to track users and store properties for them? If so, could somebody please point me in the right direction for this kind of thing? (Oh, and thanks to everybody who gave me CookieCrumbler pointers.) --- Chris --- Chris Carlson --- IS Administrator --- CertainTeed Corporation --- Waco, Texas

2 1