CST and disappearing variables
I'm running into what appears to be the same problem brought up by others several months ago regarding "random" disappearing of session variables under CoreSessionTracking. After combing through the archives, there didn't appear to be any definitive answer for the problems. I *think* my setup is fairly basic, but I can't figure out how to consistently reproduce the problem. In fact, *I* haven't been able to make it happen at all, but every 1-2 out of 10 orders ends up with an empty cart, and the customer clearly remembers their cart was not empty. I'm not using ZEO or anything fancy, just the RAM-based storage and cookies. I have the following setup for adding, updating, and viewing the cart: Python Script 'add': 'item' is a dictionary that is populated with simple numbers and strings. 'cart' is an array of 'items' and is stored like this: session = context.SDM.getSessionData() cart = session.get('cart', []) cart.append(item) session.set('cart', cart) Python Script 'update': A form passes in 'remove' as the cart index of the item to be removed: session = context.SDM.getSessionData() cart = session.get('cart', []) remove = REQUEST.form.get('remove', None) if remove is not None: del cart[remove] session.set('cart', cart) To place the items in a mail message for sending the order, I use the following simple Python Script and loop over it with dtml-in: session = context.SDM.getSessionData() return session.get('cart', []) This seems so simple, but seemingly randomly the above script returns [] instead of what is in the cart. There is another session variable (a dictionary 'custinfo') that is populated towards the end of the user's ordering process that has so far not been empty on any orders. I wish I could provide more, but I don't know what else to try. Maybe someone can see a flaw in the way I'm storing the cart that might cause CST to freak...like some persistence triggering problem or something like that. _______________________ Ron Bickers Logic Etc, Inc.
There is a bug in the RAM-based session data container implementation that causes this under load. I've fixed it in a sandbox here (more or less), but I've not had time to package it up nicely... I am so far overdue in doing this that I'm not even going to say it'll be RSN. In the meantime, please use an external data container. Many apologies, - C Ron Bickers wrote:
I'm running into what appears to be the same problem brought up by others several months ago regarding "random" disappearing of session variables under CoreSessionTracking. After combing through the archives, there didn't appear to be any definitive answer for the problems.
I *think* my setup is fairly basic, but I can't figure out how to consistently reproduce the problem. In fact, *I* haven't been able to make it happen at all, but every 1-2 out of 10 orders ends up with an empty cart, and the customer clearly remembers their cart was not empty.
I'm not using ZEO or anything fancy, just the RAM-based storage and cookies. I have the following setup for adding, updating, and viewing the cart:
Python Script 'add':
'item' is a dictionary that is populated with simple numbers and strings. 'cart' is an array of 'items' and is stored like this:
session = context.SDM.getSessionData() cart = session.get('cart', []) cart.append(item) session.set('cart', cart)
Python Script 'update':
A form passes in 'remove' as the cart index of the item to be removed:
session = context.SDM.getSessionData() cart = session.get('cart', []) remove = REQUEST.form.get('remove', None) if remove is not None: del cart[remove] session.set('cart', cart)
To place the items in a mail message for sending the order, I use the following simple Python Script and loop over it with dtml-in:
session = context.SDM.getSessionData() return session.get('cart', [])
This seems so simple, but seemingly randomly the above script returns [] instead of what is in the cart. There is another session variable (a dictionary 'custinfo') that is populated towards the end of the user's ordering process that has so far not been empty on any orders.
I wish I could provide more, but I don't know what else to try. Maybe someone can see a flaw in the way I'm storing the cart that might cause CST to freak...like some persistence triggering problem or something like that.
_______________________
Ron Bickers Logic Etc, Inc.
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
-- Chris McDonough Zope Corporation http://www.zope.org http://www.zope.com "Killing hundreds of birds with thousands of stones"
-----Original Message----- From: Chris McDonough [mailto:chrism@digicool.com]
There is a bug in the RAM-based session data container implementation that causes this under load. I've fixed it in a sandbox here (more or less), but I've not had time to package it up nicely... I am so far overdue in doing this that I'm not even going to say it'll be RSN.
Good, sort of. At least I don't have to keep pulling my hair out. Is there not a public CVS for CST?
In the meantime, please use an external data container.
It seems that using an external data container means either using an undoable storage (not recommended) or using early development versions of various external mounting and related products. Are these in fact the only current external data container solutions? What's your recommendation for a simple setup of external non-undoable storage? _______________________ Ron Bickers Logic Etc, Inc.
Good, sort of. At least I don't have to keep pulling my hair out. Is there not a public CVS for CST?
No.. unfortunately.
In the meantime, please use an external data container.
It seems that using an external data container means either using an undoable storage (not recommended) or using early development versions of various external mounting and related products. Are these in fact the only current external data container solutions? What's your recommendation for a simple setup of external non-undoable storage?
I'd use the "packless" BerkeleyStorage variant (http://www.zope.org/Products/bsddb3Storage/bsddb3Storage-1.0beta4.tar.gz/vie...) , which is nonundoing and nonversioning. Then mount a packless storage and put an external data container into it. Probably the easiest way to do this is to create a (throwaway) Zope instance initializes its "main" database into a packless storage... you just want to use the throwaway Zope to "intialize" the packless database, not to run anything on. There are instructions for doing this in the bsddb3Storage package. If you can browse the ZODB in the throwaway instance, the database is initialized. After you've got an "initialized" database, use Shane's exMount product (http://www.zope.org/Members/hathawsh/ExternalMount) to mount it into your production site's database. Alternately, use the strategy used by Randy Kern in http://www.zope.org/Members/randy/ZEO-Sessions . This docuemnt also describes the usage of externalmount. HTH and apologies again, - C
-----Original Message----- From: Chris McDonough [mailto:chrism@digicool.com]
I'd use the "packless" BerkeleyStorage variant (http://www.zope.org/Products/bsddb3Storage/bsddb3Storage-1.0beta4 .tar.gz/view)
After you've got an "initialized" database, use Shane's exMount product (http://www.zope.org/Members/hathawsh/ExternalMount) to mount it into your production site's database.
I have setup bsddb3Storage and have a storage directory initialized as you suggested. I was able to browse it in my throwaway Zope, and now it's ready to mount with ExternalMount. However, I'm not sure what to use as an external method to return the storage. I guessed this: from bsddb3Storage.Packless import Packless def createDB(): env = '/path/to/var/CSTStorage' return Packless(name='CSTStorage', env=env) But I get the following error when I try to add the external mount: Error Type: AttributeError Error Value: Packless instance has no attribute 'setClassFactory' What am I missing? Thanks! _______________________ Ron Bickers Logic Etc, Inc.
However, I'm not sure what to use as an external method to return the storage. I guessed this: ...
This seems more correct based on what I've read: import ZODB from bsddb3Storage.Packless import Packless def createDB(): env = '/path/to/var/CSTStorage' return ZODB.DB(Packless(name='CSTStorage', env=env)) But I still get an error: Error Type: AttributeError Error Value: Packless instance has no attribute 'open' Surely I'm just ignorant of something simple. _______________________ Ron Bickers Logic Etc, Inc.
Your createDB external method looks right to me... can you make sure it's "refreshed" (click save again in the mgmt UI, then restart Zope just in case).... It would be interesting to see what happened if you attempted to run it using the test tab aftewards. Ron Bickers wrote:
However, I'm not sure what to use as an external method to return the storage. I guessed this: ...
This seems more correct based on what I've read:
import ZODB from bsddb3Storage.Packless import Packless
def createDB(): env = '/path/to/var/CSTStorage' return ZODB.DB(Packless(name='CSTStorage', env=env))
But I still get an error:
Error Type: AttributeError Error Value: Packless instance has no attribute 'open'
Surely I'm just ignorant of something simple. _______________________
Ron Bickers Logic Etc, Inc.
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
-- Chris McDonough Zope Corporation http://www.zope.org http://www.zope.com "Killing hundreds of birds with thousands of stones"
-----Original Message----- From: Chris McDonough [mailto:chrism@digicool.com]
Your createDB external method looks right to me... can you make sure it's "refreshed" (click save again in the mgmt UI, then restart Zope just in case)....
Well... there is no External Method object. When adding 'Mount via External Method', I specificy the Module, Function, and Path. What I'm getting now is the following: Error Type: MountedStorageError Error Value: The path '/Test' was not found in the mountable database. It seems no matter what I put for Path, it can't be found. I've created folders using the throwaway Zope and copied the bsddb3 "environment" directory over, so the path is there. Is there a way to just specify the root of the db? I can't seem to find any docs that explain the path in any detail. So what should it be? I feel like I did a couple years ago when Zope itself had little organized documentation. Thanks! _______________________ Ron Bickers Logic Etc, Inc.
How about just "/"? I suspect that Packless is creating a new database behind your back instead of using the one you've created... Ron Bickers wrote:
-----Original Message----- From: Chris McDonough [mailto:chrism@digicool.com]
Your createDB external method looks right to me... can you make sure it's "refreshed" (click save again in the mgmt UI, then restart Zope just in case)....
Well... there is no External Method object. When adding 'Mount via External Method', I specificy the Module, Function, and Path. What I'm getting now is the following:
Error Type: MountedStorageError Error Value: The path '/Test' was not found in the mountable database.
It seems no matter what I put for Path, it can't be found. I've created folders using the throwaway Zope and copied the bsddb3 "environment" directory over, so the path is there. Is there a way to just specify the root of the db? I can't seem to find any docs that explain the path in any detail. So what should it be?
I feel like I did a couple years ago when Zope itself had little organized documentation.
Thanks! _______________________
Ron Bickers Logic Etc, Inc.
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
-- Chris McDonough Zope Corporation http://www.zope.org http://www.zope.com "Killing hundreds of birds with thousands of stones"
-----Original Message----- From: Chris McDonough [mailto:chrism@digicool.com]
How about just "/"?
ExternalMount complains that there's no id specified when I use just /.
I suspect that Packless is creating a new database behind your back instead of using the one you've created...
Could be. I did finally manage to get it working. Woohoo! I'm not exactly sure what combination of things I did to make it work :-(, but it included using a throwaway Zope instance pointing to the bsddb3 "environment" directory already in the location where I wanted it to be when mounted by the real Zope instance. After adding a Folder from the throwaway Zope, and then restarting the real Zope, ExternalMount recognized the Folder and seems to be happy now. Boy...I hope this works with CST better than I was able to set it up. :-) Thank you much for your time! _______________________ Ron Bickers Logic Etc, Inc.
Ron Bickers wrote:
ExternalMount complains that there's no id specified when I use just /.
Ah, the "path" must mean the "local" path.. the folder into which the database should be mounted... (is it becoming painfully obvious that I've never used ExternalMount ;-)?)
Could be. I did finally manage to get it working. Woohoo!
Excellent! Sorry about all the problems and thanks for sticking with it. Hope it goes smoother from here on out. -- Chris McDonough Zope Corporation http://www.zope.org http://www.zope.com "Killing hundreds of birds with thousands of stones"
-----Original Message----- From: Chris McDonough [mailto:chrism@digicool.com]
Ah, the "path" must mean the "local" path.. the folder into which the database should be mounted... (is it becoming painfully obvious that I've never used ExternalMount ;-)?)
It appears to be the path from the database to be mounted, but the last part of the path is used as the ID of the "mount point". So if I have /MyFolder in the bsddb, and I go into /OtherFolder of my main Zope ZODB and add "Mount via External Method", then I could have a Path of '/MyFolder', which would create /OtherFolder/MyFolder. This makes sense to me, but I don't know why it wasn't finding /MyFolder before.
Excellent! Sorry about all the problems and thanks for sticking with it. Hope it goes smoother from here on out.
I hope so too. We shall see. Thank you! _______________________ Ron Bickers Logic Etc, Inc.
-----Original Message----- From: Chris McDonough [mailto:chrism@digicool.com]
There is a bug in the RAM-based session data container implementation that causes this under load. I've fixed it in a sandbox here (more or less), but I've not had time to package it up nicely... I am so far overdue in doing this that I'm not even going to say it'll be RSN.
In the meantime, please use an external data container.
Sigh... After going through a semi-painful external data container setup this past weekend, I thought everything was working fine, until today we received an order with an empty cart again. :-( This was after about 12 successful orders. I can see that the external data container has items in it (7 right now) and that the internal data container has zero (as expected). I don't know what you mean by "under load", but this site gets maybe 5-10 orders per day, and that's really all there is to do there, so I consider it a *very* light traffic site. Any more suggestions? _______________________ Ron Bickers Logic Etc, Inc.
This is the first time I've heard of problems with an external data container. (10 orders a day is of course light load). I have no suggestions at the moment. A reliable way to reproduce the problem would be useful (but probably difficult). ----- Original Message ----- From: "Ron Bickers" <rbickers-dated-1002581036.893696@logicetc.com> To: <chrism@zope.com> Cc: "Zope List" <zope@zope.org> Sent: Monday, October 01, 2001 6:43 PM Subject: CST and disappearing variables (still)
-----Original Message----- From: Chris McDonough [mailto:chrism@digicool.com]
There is a bug in the RAM-based session data container implementation that causes this under load. I've fixed it in a sandbox here (more or less), but I've not had time to package it up nicely... I am so far overdue in doing this that I'm not even going to say it'll be RSN.
In the meantime, please use an external data container.
Sigh... After going through a semi-painful external data container setup this past weekend, I thought everything was working fine, until today we received an order with an empty cart again. :-( This was after about 12 successful orders.
I can see that the external data container has items in it (7 right now) and that the internal data container has zero (as expected).
I don't know what you mean by "under load", but this site gets maybe 5-10 orders per day, and that's really all there is to do there, so I consider it a *very* light traffic site.
Any more suggestions?
_______________________
Ron Bickers Logic Etc, Inc.
-----Original Message----- From: Chris McDonough [mailto:chrism@zope.com]
I have no suggestions at the moment. A reliable way to reproduce the problem would be useful (but probably difficult).
Yeah. I can't reproduce it myself no matter how many times I try. Well... back to square one then, I guess. Is there anything special I need to be concerned about regarding persistence when using CST? For example, in a Python Script, I do the following: item = {} ... populate item with some stuff ... cart = session.get('cart', []) cart.append(item) session.set('cart', cart) Is this something that CST should be able to handle properly? The only other thing I do that might be strange is getting the session data more than once in a transaction as follows: When the final Python Script 'sendOrder' is called from the Web, it goes something like this: session = context.SDM.getSessionData() message = container.message(container, custinfo=session['custinfo']) ... send message ... The DTML Method 'message' called above has this: <dtml-with custinfo mapping> ... name, address, etc. variables from 'custinfo' ... </dtml-with> <dtml-var textview> The DTML Method 'textview' inserted at the end of the 'message' has this: <dtml-let items="Items()"> <dtml-unless items> Your cart is empty. </dtml-unless> <dtml-if items> <dtml-in items mapping> ... display items ... </dtml-in> </dtml-if> The Python Script 'Items' is as follows: session = context.SDM.getSessionData() return session.get('cart', []) So, 'textview' calls the Python Script 'Items' which gets the session data again. Is there anything wrong with doing this, or can you see anything dangerous in my logic? It seems so clear and simple to me, but I'm questioning pretty much everything now. Thanks for your help. _______________________ Ron Bickers Logic Etc, Inc.
Is there anything special I need to be concerned about regarding
persistence
when using CST?
Just what's in the documentation.. which by the rest of your message it appears you've already read (or you intuited the right way of doing things).
For example, in a Python Script, I do the following:
item = {} ... populate item with some stuff ...
cart = session.get('cart', []) cart.append(item) session.set('cart', cart)
Is this something that CST should be able to handle properly?
Yes... the last session.set is necessary due to the mutability of "cart", but you knew that.
The only other thing I do that might be strange is getting the session data more than once in a transaction as follows:
When the final Python Script 'sendOrder' is called from the Web, it goes something like this:
session = context.SDM.getSessionData() message = container.message(container, custinfo=session['custinfo']) ... send message ...
The DTML Method 'message' called above has this:
<dtml-with custinfo mapping> ... name, address, etc. variables from 'custinfo' ... </dtml-with>
<dtml-var textview>
The DTML Method 'textview' inserted at the end of the 'message' has this:
<dtml-let items="Items()"> <dtml-unless items> Your cart is empty. </dtml-unless> <dtml-if items> <dtml-in items mapping> ... display items ... </dtml-in> </dtml-if>
The Python Script 'Items' is as follows:
session = context.SDM.getSessionData() return session.get('cart', [])
So, 'textview' calls the Python Script 'Items' which gets the session data again. Is there anything wrong with doing this, or can you see anything dangerous in my logic? It seems so clear and simple to me, but I'm questioning pretty much everything now.
No, it seems normal. :-( Darn. You're not working with multiple frames or windows, are you? -- Chris McDonough Zope Corporation http://www.zope.org http://www.zope.com "Killing hundreds of birds with thousands of stones"
-----Original Message----- From: Chris McDonough [mailto:chrism@digicool.com]
No, it seems normal. :-( Darn.
You're not working with multiple frames or windows, are you?
Nope. Any suggestions on how I could set something up to gather debugging information? Like placing something (though I'm not sure what) in various places in my code to log whatever may be going on with the request and session? I'm just grabbing at straws now. I really have no idea where to go with this, but I'm nervous about starting a large upcoming project that would use CST quite a bit when I'm having random problems. _______________________ Ron Bickers Logic Etc, Inc.
It'd be useful to have a log of session activity for session start and end (use the sessioning onStart and onEnd mechanisms to do this) as well as a log method to use before you access a session data object.. you could make a couple external methods that log session events to the STUPID_LOG. An onstart script follows: def sessionOnStart(self, sdo): sdm = self.SDM isnew = sdm.isTokenNew() sd_sid = sdo.id sd_pyid = id(sdo) s = "%s pyid %s sid %s" % (isnew and 'new token ' or '', sd_pyid, sd_sid) from zLOG import LOG, INFO LOG('Session onStart', INFO, s) An onend script follows: def sessionOnEnd(self, sdo): from zLOG import LOG LOG('Session info', zLOG.INFO, 'Session sid %s ending' % sdo.id) Additionally, before you access any sessioning stuff in your code it would be useful to call a logging method like this: def logSessionInfo(self, sdm, from=''): sdo = sdm.getSessionData() isnew = sdm.isTokenNew() sd_sid = sdo.id sd_pyid = id(sdo) sd_len = len(sdo) s = "%s pyid %s sid %s len%s" % (isnew and 'new token ' or '', sd_pyid, sd_sid, sd_len) from zLOG import LOG, INFO LOG('Session info (%s)' % from, INFO, s) Use this method like so from dtml *before* every call to your sessioning machinery. <dtml-call "logSessionInfo(SDM, 'test method')"> When you run into a situation where you suspect a sessioning problem, send me the relevant time period from the logfile (set via STUPID_LOG_FILE). HTH, - C ----- Original Message ----- From: "Ron Bickers" <rbickers-dated-1002597560.27f40d@logicetc.com> To: <chrism@zope.com> Cc: "Zope List" <zope@zope.org> Sent: Monday, October 01, 2001 11:19 PM Subject: RE: [Zope] RE: CST and disappearing variables (still)
-----Original Message----- From: Chris McDonough [mailto:chrism@digicool.com]
No, it seems normal. :-( Darn.
You're not working with multiple frames or windows, are you?
Nope.
Any suggestions on how I could set something up to gather debugging information? Like placing something (though I'm not sure what) in various places in my code to log whatever may be going on with the request and session?
I'm just grabbing at straws now. I really have no idea where to go with this, but I'm nervous about starting a large upcoming project that would use CST quite a bit when I'm having random problems.
_______________________
Ron Bickers Logic Etc, Inc.
-----Original Message----- From: Chris McDonough [mailto:chrism@zope.com]
It'd be useful to have a log of session activity for session start and end (use the sessioning onStart and onEnd mechanisms to do this) as well as a log method to use before you access a session data object.. you could make a couple external methods that log session events to the STUPID_LOG.
Done. For my specific application, I added to a little logic to logSessionInfo to show when the cart a) doesn't exist or b) the number of items in it if it does exist. I'll let you know when the problem shows up again. Thanks! _______________________ Ron Bickers Logic Etc, Inc.
-----Original Message----- From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of Ron Bickers
I'll let you know when the problem shows up again.
Just got an empty cart, and the session log tells all. I'm a bit stunned, but maybe I shouldn't be. Users do strange things sometimes. 2001-10-02T18:54:30 INFO(0) Session START new token pyid 159677656 sid 40656853Az-57oGmXPc ip 24.88.58.162 2001-10-02T18:54:30 INFO(0) Session CALL (add [get]) new token pyid 146506488 sid 40656853Az-57oGmXPc len 0 cart None 2001-10-02T18:54:30 INFO(0) Session CALL (add [set]) new token pyid 147932800 sid 40656853Az-57oGmXPc len 0 cart None 2001-10-02T18:54:30 INFO(0) Session CALL (Items [get]) pyid 147444240 sid 40656853Az-57oGmXPc len 1 cart 1 2001-10-02T19:56:57 INFO(0) Session END sid 40656853Az-57oGmXPc 2001-10-03T13:40:19 INFO(0) Session START pyid 148619840 sid 40656853Az-57oGmXPc ip 24.88.58.162 2001-10-03T13:40:19 INFO(0) Session CALL (checkout [get]) pyid 143714000 sid 40656853Az-57oGmXPc len 0 cart None 2001-10-03T13:41:54 INFO(0) Session CALL (gatherCheckout [set]) pyid 143320024 sid 40656853Az-57oGmXPc len 0 cart None 2001-10-03T13:41:55 INFO(0) Session CALL (checkout [get]) pyid 143064448 sid 40656853Az-57oGmXPc len 1 cart None 2001-10-03T13:47:02 INFO(0) Session CALL (gatherCheckout [set]) pyid 142953384 sid 40656853Az-57oGmXPc len 1 cart None 2001-10-03T13:47:02 INFO(0) Session CALL (verify [get]) pyid 143623016 sid 40656853Az-57oGmXPc len 1 cart None 2001-10-03T13:47:02 INFO(0) Session CALL (Items [get]) pyid 144859400 sid 40656853Az-57oGmXPc len 1 cart None 2001-10-03T13:47:24 INFO(0) Session CALL (Items [get]) pyid 144859400 sid 40656853Az-57oGmXPc len 1 cart None 2001-10-03T13:47:24 INFO(0) Session CALL (Items [get]) pyid 143947112 sid 40656853Az-57oGmXPc len 1 cart None 2001-10-03T13:47:25 INFO(0) Session CALL (sendOrder [invalidate]) pyid 145079240 sid 40656853Az-57oGmXPc len 1 cart None 2001-10-03T13:47:25 INFO(0) Session END sid 40656853Az-57oGmXPc Here's how it went... 1) User adds item to their cart then goes to bed! 2) Session times out about an hour later as configured. 3) User sits down 19 hours later and selects "checkout" from a cart that still shows from yesterday but is really empty. 4) User fills out billing/shipping information. 5) User is *supposed* to verify their order at which point they should have noticed that the cart says it is *empty* right next to the "send order" link. 6) User doesn't bother paying attention. Instead, they send an empty order. I guess I should handle this in my application by not allowing it to be sent at the end when the cart is empty. They're already not allowed to checkout when the cart is empty, but I wrongly assumed the user would add items to their cart and checkout in the same sitting. That was stupid of me considering I just did a similar thing the other day. I wanted to "sleep on it" to make sure I got everything I needed in one shipment. In addition to fixing my application, is there any reason not to make the session timeout a large number, like 2 days? Thanks! _______________________ Ron Bickers Logic Etc, Inc.
Wow! Logs tell excellent stories!
In addition to fixing my application, is there any reason not to make the session timeout a large number, like 2 days?
Not really... you could even make it "infinite" by entering 0. Using an external session data container, this is OK because RAM consumption won't grow out of bound. Additionally, the session data persists between shutdowns. Thanks for letting me know about this! I'm sorry you had these problems but it feels good to not suspect CST of having a bug with external data containers. - C
-----Original Message----- From: Chris McDonough [mailto:chrism@zope.com]
Wow! Logs tell excellent stories!
Indeed they do. Thanks for your methods on setting it up. Have you considered adding optional logging to CST itself for easier debugging?
Not really... you could even make it "infinite" by entering 0. Using an external session data container, this is OK because RAM consumption won't grow out of bound. Additionally, the session data persists between shutdowns.
Ok. I'll probably just make it some large number so it gets cleaned up at least at some point, but still modify my application to help the stupid. Why is it that the session data is deleted when the timeout is changed? I may confuse a lot of people that are in the process of placing orders when I change this.
Thanks for letting me know about this! I'm sorry you had these problems but it feels good to not suspect CST of having a bug with external data containers.
Agreed. I feel much better about CST now. I've been wanting to use an external container anyway for the persistence between shutdowns, I just didn't expect to have to do it like this. Thanks again for all your help! Go ZC! _______________________ Ron Bickers Logic Etc, Inc.
participants (15)
-
Chris McDonough -
Chris McDonough -
Ron Bickers -
Ron Bickers -
Ron Bickers -
Ron Bickers -
Ron Bickers -
Ron Bickers -
Ron Bickers -
Ron Bickers -
Ron Bickers -
Ron Bickers -
Ron Bickers -
Ron Bickers -
Ron Bickers