(I apologise in advance for the crosspost, but I think this is a valid question on both the zope-db and zope-dev lists. If you disagree, flame away, and I'll never do it again. oh, btw: flame in private mail, please) Hello! We have run into a showstopper problem here where it seems (we're not sure yet) that there is a severe problem using dates returned from the Oracle DA adapter. Other possible culprits include LocalFS, Transparent Folder, Formulator and the source release of Zope 2.4.1. The problem is that Zope either dies, core dumps and dies, or slows down to a crawl. We are using the Zope 2.4.1 release, with Transparent folders and LocalFS, latest, and a sligthly modified Formulator. There are about 2-6 people working and developing in it during all hours of the day (24 hours). Unfortunately nothing shows up in any of the logs, so they are of little use; I don't even have a traceback so display. We *think* we found sometign pointing at LocalFS in one of the coredumps, but we are lowly non-unix programmers, and have no idea if this is accurate info or not. It could just be un-collected garabage memory. Is anybody noticing anything similar, or if you have any opinion on what might be going on, please reply; we are in DS mode here (we are having a prototype presentation during two weeks, starting tomorrow) and are feeling a bit desperate. Sincerely, /dario - -------------------------------------------------------------------- Dario Lopez-Kästen Systems Developer Chalmers Univ. of Technology dario@ita.chalmers.se ICQ will yield no hits IT Systems & Services
Hello Dario, Just noticed behaviour similar to this a couple of days ago , but haven't had the time to file a report on it.. - We managed to narrow it down a bit , tho' : In our installation ; Zope silently restarted , quite quickly , and almost unnoticeable to our editors. This was triggered either when we passed one of the oracle-date-objects returned by DCO2 to DateTime(), or when we believed them to be DateTime objects and tried to run DateTime methods on them... I was in a production environment , so i had to fix the errors before going to work on narrowing down the bug. Selecting your dates as strings with TO_CHAR(datefield) in your SQL will be a safeguard against the restarting/crashing/whatever_bad_things_might_happen , but will give you boring strings instead of date-objects.. -ok , it is a stopgap, but my Zope stopped restarting every 2 minutes... Hoop we can get this fixed before the final is released.. :-) Monday, October 01, 2001, 15:06:44, you wrote: DLK> (I apologise in advance for the crosspost, but I think this is a valid DLK> question on both the zope-db and zope-dev lists. If you disagree, flame DLK> away, and I'll never do it again. oh, btw: flame in private mail, please) DLK> Hello! DLK> We have run into a showstopper problem here where it seems (we're not sure DLK> yet) that there is a severe problem using dates returned from the Oracle DA DLK> adapter. Other possible culprits include LocalFS, Transparent Folder, DLK> Formulator and the source release of Zope 2.4.1. DLK> The problem is that Zope either dies, core dumps and dies, or slows down to DLK> a crawl. DLK> We are using the Zope 2.4.1 release, with Transparent folders and LocalFS, DLK> latest, and a sligthly modified Formulator. DLK> There are about 2-6 people working and developing in it during all hours of DLK> the day (24 hours). DLK> Unfortunately nothing shows up in any of the logs, so they are of little DLK> use; I don't even have a traceback so display. We *think* we found sometign DLK> pointing at LocalFS in one of the coredumps, but we are lowly non-unix DLK> programmers, and have no idea if this is accurate info or not. It could just DLK> be un-collected garabage memory. DLK> Is anybody noticing anything similar, or if you have any opinion on what DLK> might be going on, please reply; we are in DS mode here (we are having a DLK> prototype presentation during two weeks, starting tomorrow) and are feeling DLK> a bit desperate. DLK> Sincerely, DLK> /dario -- Geir Bækholt web-developer/zopatista geirh@funcom.com funcom oslo | webdev-team
Geir Bækholt wrote:
Hello Dario,
Just noticed behaviour similar to this a couple of days ago , but haven't had the time to file a report on it.. - We managed to narrow it down a bit , tho' :
In our installation ; Zope silently restarted , quite quickly , and almost unnoticeable to our editors. This was triggered either when we passed one of the oracle-date-objects returned by DCO2 to DateTime(), or when we believed them to be DateTime objects and tried to run DateTime methods on them...
I was in a production environment , so i had to fix the errors before going to work on narrowing down the bug. Selecting your dates as strings with TO_CHAR(datefield) in your SQL will be a safeguard against the restarting/crashing/whatever_bad_things_might_happen , but will give you boring strings instead of date-objects.. -ok , it is a stopgap, but my Zope stopped restarting every 2 minutes...
Hoop we can get this fixed before the final is released.. :-)
So what you REALLY want is the ZOracleDA to promote the weakling dco2.DateTime objects to full Zope DateTime objects. Aha! I think that's doable in short order.
Matthew T. Kromer wrote:
Geir Bækholt wrote:
Hello Dario, Just noticed behaviour similar to this a couple of days ago , but haven't had the time to file a report on it.. - We managed to narrow it down a bit , tho' :
In our installation ; Zope silently restarted , quite quickly , and almost unnoticeable to our editors. This was triggered either when we passed one of the oracle-date-objects returned by DCO2 to DateTime(), or when we believed them to be DateTime objects and tried to run DateTime methods on them...
So what you REALLY want is the ZOracleDA to promote the weakling dco2.DateTime objects to full Zope DateTime objects.
Aha!
I think that's doable in short order.
In fact, here's the simple patch (only the last bit is really necessary, but as long as I was looking at it I tweaked the listtype to be a pseudo-constant as an argument. I've checked it in to CVS too :) Index: db.py =================================================================== RCS file: /cvs-repository/Products/DCOracle2/db.py,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- db.py 14 Sep 2001 15:11:19 -0000 1.8 +++ db.py 2 Oct 2001 21:13:58 -0000 1.9 @@ -83,8 +83,8 @@ # ############################################################################## -'''$Id: db.py,v 1.8 2001/09/14 15:11:19 matt Exp $''' -__version__='$Revision: 1.8 $'[11:-2] +'''$Id: db.py,v 1.9 2001/10/02 21:13:58 matt Exp $''' +__version__='$Revision: 1.9 $'[11:-2] import DCOracle2, DateTime #DCOracle.dbi.dbiDate=DateTime.DateTime @@ -230,12 +230,14 @@ # # Do we get tuples back in results? should just be lists # - def _lobConvert(self, result): + def _lobConvert(self, result, listtype=type([])): for i in xrange(len(result)): t = type(result[i]) - if t == type([]): self._lobConvert(result[i]) + if t == listtype: self._lobConvert(result[i]) elif t == DCOracle2.dco2.LobLocatorType: result[i] = LobLocator(result[i]) + elif t == DCOracle2.dco2.OracleDateType: + result[i] = DateTime.DateTime(float(result[i])) # Added for ChrisM (11/13/2000 MTK) def commit_sub(self, *arg, **kw):
participants (3)
-
Dario Lopez-Kästen -
Geir Bækholt -
Matthew T. Kromer